This depends in some part on your adder design. For the simplest adder, a ripple-carry adder, your power consumption is gong to scale with the width of the add

This depends in some part on your adder design. For the simplest adder, a ripple-carry adder, your power consumption is gong to scale with the width of the adder and an addition will take time proportional to the width to perform, with an energy cost proportional to to the width. This sort of adder doesn't really have any long lines for carrying bits long distances, everything is local once the data arrives at the adder. With carry-bypass or carry-lookahead you have a time of the square root of the width and the costs are both proportional to the width, a constant factor larger than with a ripple adder. These are the ones used in most higher performance CPUs, or were back in 2007 when I thesing. You have some long lines here but never more than square root width and a small number compared to the number of transistors. With tree adders you can add numbers in time proportional to the log of the width, costing a number of gates that grows as the square of the width. Now, if you assume that the inputs are all equally likely to be ones or zeros with no correlations then carry chains aren't likely to propagate very far up the tree. But as you point out if you happen to have an addition that creates a long carry chain then you'll end up switching most of the gates and using a lot of power. One of the things in my thesis that was actually practically useful was showing that you do frequently get long carry chains on real data meaning that the naive approach of counting gates works better for analyzing tree adders than trying to derive activity factors from simplified models of the inputs. These ones also have particularly long lines that have to be switched for long carry chains, and lots of them. I got my data from using this tool Intel puts out to instrument binaries like, say, 'ls' or 'mozilla' and reading out the inputs for every use of the adder. Well, random stretches of 100 uses anyways for the browser, otherwise I wouldn't have been able to store enough data.