6894779: Loop Predication for Loop Optimizer in C2
This work implements the loop predication optimization for range check elimination,
and null check elimination, etc., for the loop optimizer in C2. It was initiated by Ross

The idea is to insert a predicate on the entry path to a loop, and raise a uncommon trap
if the check of the condition(s) fails. The condition checks are promoted from inside the
loop body, and thus the checks inside the loop could be eliminated.

While the loop predication is a framework, it could be applied to range check, null check, and
array check eliminations, etc. Loop predication has advantage over the existing iteration-splitting
based range check elimination, and loop peeling based null check and array check eliminations. First,
it does not increase the code size (but the iteration splitting, and loop peeling do increase the code
size significantly), so we can apply loop predication to outer loops without the conscern of code size
increment. Second, while the iteration spliting based range check elimination leaves range checks in the pre-
and post- loops not removed, loop predication does not split the loop, and thus the range checks could be
eliminated for the whole loop body.

Known Issues:
(1) Missing Loop Predicate
The loop predication relies on the loop predicate inserted at the parsing time. If for some reasons, the loop predicate
was not inserted, or the predicate-loop pattern was destroyed by other optimizations, we can not perform loop predication.
We know that the predicate is not inserted for loops from inline_intrinsics, and there is no predicate for new loops generated
in the optimizer. Some of the cases need further investigation
Currently predicate is inserted on each entry path to loop head. This will cause problem when a loop has more than one entry.
beautify_loop in the loop optimizer will merger the paths into one using "landing_pad" and there will be no predicate on the merged
path to the loop head
(2) Missing Loop Predication Opportunities
We walk through the idom tree in a loop from its tail to head to find range check and null check for eliminations. Checks within
a dismond shape were not considered. An example is " if (condition(i)) {a[i] = ...}". Without further analysis of condition(i), we
can not eliminate the range check for a[i]
(3) Single Uncommon Trap for Multiple Reasons
If one of the checks fails, we will disable loop predication optimization for the whole method. For example, array_check fails for some
specjvm2008 workloads (serial, compiler) (You may use -XX:+TraceLoopPredicate to take a look). The problem is that we can not distinguish whether it
is a array check failure and other check failure. So for the next compilation, loop predication will be disabled.