RFR: 8319793: C2 compilation fails with "Bad graph detected in build_loop_late" after JDK-8279888 [v9]

[Emanuel Peter]

On Fri, 5 Jan 2024 09:53:09 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Ah. Does this mean that if there are multiple RangeCheck in a loop, where some could be smeared, these are not smeared, and then we have more RangeChecks to eliminate out of the loop? Maybe in the end this all comes down to the same anyway. Just wondering.
>
>> Why is it ok to delay this to post-loop-opts? Does it not prevent moving some CFG from being eliminated out of loops? Would be nice to have a little justification comment.
> 
> Maybe. With this fix, range check smearing requires pinning nodes. So running it early also has a drawback: it can cause nodes that would otherwise float to be pinned. The way I see it, range check smearing is a local optimization for cases where range checks can't be eliminated some other way so running it late should not make a difference. If the range check is in a loop and predication removes it then running RC smearing early doesn't make a difference. If the range check is part of a range check sequence that can only be optimized by RC smearing then having a longer range check sequence for the duration of loop opts probably makes no difference.

@rwestrel would you mind explaining exactly that in a comment? Something like:

We are about to perform range check smearing (i.e. remove this RangeCheck if it is dominated
by two RangeChecks which have a range that covers the this RangeCheck). This can cause
nodes to be pinned. We want to avoid that and first allow RangeCheckElimination a chance to
remove the RangeChecks from loops. Hence, we delay range check smearing until after loop opts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16886#discussion_r1446106265