https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69943
--- Comment #3 from Peter Cordes <peter at cordes dot ca> --- (In reply to ktkachov from comment #2) > On second thought, reassociating signed addition is not legal in general > because we might introduce signed overflow where one didn't exist before. In an intermediate result, yes. The final result can't change on 2's complement hardware, though, so it's a legal optimization. Good thinking that the compiler might treat signed and unsigned integers differently, though. You only need to avoid it on hardware where signed overflow has side-effects. (e.g. setting a "sticky" flag that can be checked after a sequence of operations to see if there were any overflows along the way.) And I think MIPS has signed vs. unsigned add instructions, and can raise an exception? Anyway, x86 doesn't have any of those things, and the calling convention lets flags be in any arbitrary state when the function return. So this optimization is valid for signed integers on x86. BTW, using unsigned results in two LEA instructions, even though there's still a MOV from memory. ADD is shorter to encode, and can run on more execution ports. It also has higher latency on Atom.
