Convert Loop Metadata to Asserts to help Loop rotation

[F-Stuckmann]

note the first commit will be removed once the ( #225 ) is merged

Please note: I am still going through QoR to make sure I am not introducing any functional errors.

[andcarminati]

Maybe you can fix the CI failure by running your test under x86?

[F-Stuckmann]

I moved the pass between LICM and loop rotate, so that the loop invariance check is simplified and performed by LICM. This behavior is demonstrated by unittests.

Additionally, the assumption is inserted into the Preheader, so that the loop header is not evaluated to true and converted into an endless loop.

[F-Stuckmann]

• Assumption Insertion: Evaluate at MinIterCount to not introduce loop guards after loop unrolling
• Assumption Insertion: Evaluate at Iteration 0, so that EQ/NE and variable stepsizes can be processed. Hint: EQ/NE only get this assumption inserted

I also only lazily insert the Iteration 0 assumption so that the IR changes are minimal.

QoR improves by 1.14% and program memory by 0.73%, when this pass is enabled vs with the builtin_assumes

[gbossu]

is that dead code?

[F-Stuckmann]

Yes, adding the second assumption may help us not run into the unroll trap.

We always insert NE assumptions, even with EQ predicates, since it is an abort criterium to exit the loop (in which case we invert the predicate for the assumption generation).

[gbossu]

Yes I missed that the previous if isn't an early return. Does that mean that for predicates other than NE/EQ, we might insert two types of assumptions? How does hasVariableStepSize work actually? Won't insertIterationAssumption bail out because it can find neither an AddRec nor a loop-invariant value?

[gbossu]

Oh I think I start to understand, the operand could be a SCEVAddRecExpr of degree >1, in which case the step is itself a SCEVAddRecExpr. But still, why does that need to be handled specifically? Why not just evaluate the SCEV at iteration MinIterCount - 1?

[F-Stuckmann]

yes we insert two assumptions. with variable StepSizes, AddRec is actually found and the Stepsize is now a Value instead of a Constant.

Consider the following:

for (int i =0; i < n; i+=m) {
}

If we only add MinIterCount - 1 assumption, we only guarantee, that m* (MinIterCount-1) < n , but this does not guarantee, that we will actually enter the loop. Consider m to be negative. We then guarantee, that n is negative. But we don't actually guarantee, that we enter the loop the first time.
Therefore we also have to guarantee that by also adding 0 < n.

With NE this is even more clear

for (int i=0 ; i != n ; i++) {
}

MinIterCount-1 != n, does not actually guarantee, that we will enter the loop, since we don't know if n != 0 is true

[gbossu]

Could we potentially run the pass twice?

[F-Stuckmann]

We run the pass and then immediately rotate the loop.

So on the second entry, we already have a rotated loop and bail

[gbossu]

or simplify to a MulExpr, is this really true? Do you have a test that shows this example?

[F-Stuckmann]

yes, for example this unit test LoopVariantUpperBound

[F-Stuckmann]

it always occurs, when we have a variable stepsize and start of 0

[F-Stuckmann]

I wasn't sure if adding a reference to a unittest would be appropriate

[gbossu]

Oh right, that makes sense. Somehow I read it as "recursive" MulExpr, but this here simply represents a multiplication of two SCEVs.