RFR: 8333393: PhaseCFG::insert_anti_dependences can fail to raise LCAs and to add necessary anti-dependence edges [v13]

[Emanuel Peter]

On Wed, 5 Feb 2025 14:29:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Daniel Lundén has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/hotspot/jtreg/compiler/codegen/TestGCMLoadPlacement.java
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/opto/gcm.cpp line 831:
> 
>> 829:   // | 8 membar_release <- 7 | early
>> 830:   // | ...                   |
>> 831:   // +-----------------------+
> 
> I just discussed this example with @chhagedorn 
> 
> // Patch the existing phi to select an input from the merge:
> // Phi:AT1(...MergeMem(m0, m1, m2)...) into
> //     Phi:AT1(...m1...)
> int alias_idx = phase->C->get_alias_index(at);
> 
> And
> 
>         // Phi(...MergeMem(m0, m1:AT1, m2:AT2)...) into
>         //     MergeMem(Phi(...m0...), Phi:AT1(...m1...), Phi:AT2(...m2...))
> 
> 
> In `cfgnode.cpp`, we try to move the MergeMem after Phi. Why does this not happen in this example?
> 
> There are many cases in that code... but it seems to me that here something may be missing. I have not given it more time though.
> 
> If we knew that MergeMem always happened after the Phi, then we could only search from the `initial_mem`, and would walk through all relevant MergeMem, right?
> 
> This is just an intuition, but maybe having MergeMem after Phi is a fundamental assumption. Or maybe it just happens in all cases, and yours is the only we found so far where that is not possible.
> 
> What do you think?

@dlunde I really don't want to block you here. I never understood the memory graph above the initial mem. Now that I see the example I'm getting new ideas 😅

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22852#discussion_r1943052008