RFR: 8325746: Refactor Loop Unswitching code [v3]

[Christian Hagedorn]

On Wed, 14 Feb 2024 12:59:28 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Ah yes, makes sense!
>> Maybe add a small comment about loop peeling then? Just because you do mention that we don't handle exits, that automatically raises that question.
>
>> Ah yes, makes sense! Maybe add a small comment about loop peeling then? Just because you do mention that we don't handle exits, that automatically raises that question.
> 
> I'll add a comment.
> 
>> Make sure to be consistent. I think you use if-path and if-block as synonymes, right?
> Btw: are these only blocks, as in basic blocks, and hence the if-statements are only such "basic diamonds", that only have one block per if-else side? Or could the CFG be more complex?
> 
> The only requirement for Loop Unswitching is that both paths are inside the loop (I make this more explicit in the header comment together with mentioning loop peeling as alternative for loop-exiting tests). When this is given, we will at some point merge both paths again with a region. So, yes, I use if-path and if-block interchangeable. I've cleaned that up in the comments.
> 
> For example, this example can also be unswitched on `flag` with a more complex CFG and even with a method call:
> 
> 
> static int iFld;
> static boolean flag2;
> 
> // Run with -Xcomp.
> static void test() {
>     boolean flag = iFld < 3;
>     for (int i = 0; i < 1000; i++) {
>         if (flag) {
>             iFld = 34;
>             if (flag2) {
>                 dontInline();
>             }
>         }
>     }
> }

I've rewritten this paragraph inspired by your suggestions. Please have another look at it :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17842#discussion_r1489469025