RFR: 8317723: C2: CountedLoopEndNodes and Zero Trip Guards are wrongly treated as Runtime Predicate

[Emanuel Peter]

On Fri, 10 Nov 2023 08:53:29 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> In `testCountedLoopEndAsRuntimePredicate()`, a `CountedLoopEndNode` is wrongly treated as Runtime Predicate and added to a Predicate Block. This happens because a predicate trap ends up at one of the projections of the `CountedLoopEndNode` due to folding some other nodes:
> 
> ![image](https://github.com/openjdk/jdk/assets/17833009/d00af4aa-e962-454f-b7cd-5984dfda293f)
> 
> The verification code then reports this failure when trying to find all predicates above `530 CountedLoop`. I've fixed `RuntimePredicate::is_success_proj()` to only treat an `IfNode` or a `RangeCheckNode` as Runtime Predicate.
> 
> We could also end up treating a zero trip guard If node with an `OpaqueZeroTripGuardNode` as Runtime Predicate (see `testZeroTripGuardAsRuntimePredicate()`):
> 
> ![image](https://github.com/openjdk/jdk/assets/17833009/a515bdfb-b599-4a81-902c-e85b980f5899)
> 
> This could also potentially lead to problems. I've improved `RuntimePredicate::is_success_proj()` to additionally exclude zero trip guard checks. I've strengthened the verification code accordingly such that it would have failed with  `testZeroTripGuardAsRuntimePredicate()`.
> 
> Thanks,
> Christian

The solution looks reasonable.

But I wonder if there could not be a scenario, where we have some "normal" if (i.e. a condition stated by the user in java code), which has a loop on both sides of the condition. If now one side collapses to a bare uncommon trap, this if would look like a runtime predicate, right? Is this impossible? If not, we may need a more fundamental solution. Maybe some new (sub)class of node, or a flag in the If node.

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

PR Review: https://git.openjdk.org/jdk/pull/16596#pullrequestreview-1729174959