RFR(M): 8223051: support loops with long (64b) trip counts

[Roland Westrelin]

> But it also means there should be always a safepoint accompanying the 
> call and it should follow it immediately for the logic in question to be 
> in effect. Do we guarantee that?

In general, it's not guaranteed that there's a safepoint above the loop
exit test. We plant SafePointNodes on back branches in the bytecodes but
if the destination of the backbranch is not the loop head then the
SafePointNode is not above the exit test. If the SafePointNode is not
right above the exit test, the current logic looks for a dominating one
in the loop body and checks that there's no side effects between the
safepoint and the exit test.

So it's possible that we can't find a suitable safepoint in which case
the transformation can proceed but without predicates for the inner loop
(unless the exit test is a not equal test because then a loop limit
check is likely required). So even if we find no safepoint, there's a
good chance we can transform the loop and do a fair job of optimizing
it.

I ran ctw on the base module with the stress option that transforms an
int counted loop to a long loop and back to an int counted loop nest to
estimate how common it is that no suitable safepoint is found and there
was only a handful of them.

So it's possible that we end up with a loop that doesn't have a
safepoint but the loop has a call that dominates the exit test and we
could use its jvm state but it seems like a rare corner case so I don't
think the extra complexity is worth it. We could revisit this if it
turns out to be a common enough code pattern.

Roland.