RFR: 8303466: C2: failed: malformed control flow. Limit type made precise with MaxL/MinL [v4]

[Emanuel Peter]

On Tue, 11 Apr 2023 19:18:16 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>>>If we have several unrolls we will have chain of MaxL/MinL nodes. Will the chain be folded by IGVN?
>> 
>> @vnkozlov I fear it would not fold currently. The CMove would not fold before either, but with repeated unrolling, the CMove was reused, and so there was only ever a single CMove (unless some RC got in between).
>> 
>> I think in many cases, the type does not underflow, and the `MaxL/MinL` can be removed completely.
>> However, if that does not work, I think it now also fails to remove the repeated `ConvI2L / ConvL2I`. We would have to add more IGVN optimizations to fold things more.
>> 
>> I think the performance impact is now insignificant, if it does not fold. Because the limits are only calculated once per loop. We can still improve the folding, if you want. I can also do that in a follow-up RFE, and try to add some IR tests that target type-limit underflow, and count the `MaxL/MinL` nodes.
>> 
>> TLDR: @vnkozlov is it ok if I investingate & test `MaxL/MinL` and `ConvI2L / ConvL2I` folding in a follow-up RFE?
>
>> However, if that does not work, I think it now also fails to remove the repeated ConvI2L / ConvL2I. We would have to add more IGVN optimizations to fold things more.
> 
> I think you're running into an issue where some nodes created by counted loop expansion aren't properly passed onto the IGVN worklist- I found the same thing while trying to investigate some strange code generation from small loops. If you make that follow-up RFE I would be happy to attach the cases that I found as well.

@jaskarth please send me those cases, if it is many then maybe better via email. I'm generally working on doing verification of that kind, see [JDK-8298951](https://bugs.openjdk.org/browse/JDK-8298951).

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

PR Comment: https://git.openjdk.org/jdk/pull/13269#issuecomment-1507385614