[Bug tree-optimization/69943] expressions with multiple associative operators don't always create instruction-level parallelism

["peter at cordes dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

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.