Push down constants in AddNode

[jcdavis]

The current reassociate call only handles cases such as (A+C1) + C2. This adds cases for (X+C1)+Y and X+(Y+C2), which allows simplifying

      (A+1)+(B+2)
    =>(A+(B+2))+1
    =>((A+B)+2)+1

from which the existing reassociate will pull out the 2 and we end up with (A+B)+3

[tkrodriguez]

As @gilles-duboscq suggested this could interact with loop invariant reassociation but that I think that's true of any reassociation so I don't think it matters for this change. I"ll push once this passes the gate.

[jcdavis]

What's the correct way to avoid the eclipse comment formatter rewriting here?
@formatter:on and @formatter:off ?

[dougxc]

Yes, for example

graal/truffle/src/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/vm/ImplicitExplicitExportTest.java

Lines 103 to 111 in 7319658

	// @formatter:off
	vm.eval(
	Source.newBuilder("implicit.ahoj=42").
	name("Fourty two").
	mimeType(L1).
	build()
	);
	Object ret = vm.findGlobalSymbol("ahoj").get();
	// @formatter:on

[gilles-duboscq]

Why not do this in the reassociate code? If it is useful for constants i guess it's also useful for loop invariants.

we must check this add isn't a loop induction variable, since reassociation can break loop analysis

I'm wondering what particular problem you are trying to avoid there.
In principle rotating the operation shouldn't change the IV nature of the node so maybe we have an issue somewhere else?

More importantly, this transformation might also create more work: i think we should be more careful about the cases where the intermediate node has usages.
If in x + (y + c), y + c has usages, we will end up with (x + y) + c and y + c in the IR. At the best this will lead to a further reassociation and we would only break-even but otherwise we have just introduced one more +.