We have now seen two miscompiles because of widening widenable
conditions at incorrect IR points and thereby changing a branch's loop
invariant condition to a loop-varying one (see PR60234 and PR61963).
This patch adds asserts in common guard utilities that we use for
widening to proactively catch these bugs in future.
Note that these asserts will not fire if we were to sink a widenable
condition from out of a loop into a loop (that's also incorrect for the
same reason as above).
Tested this without the fix for PR60234 (guard widening miscompile) and
confirmed the assert fires.
This might be too strict. L->isLoopInvariant is only checking placement of instruction. Imagine you have invariant a and b and WidenableBr->getCondition() = add a, b. It is still invariant, no matter if the actual add instruction is placed inside of loop or not. Or, for example, condition is a load marked as !invariant_load; it's still same value no matter where we move it.
If we had SCEV, the good approximation for what we want is isAvailableAtLoopEntry; we need something similar with instructions.
I mean, we *can* go this strict way, but be ready that it will fail when there is no real bug.