RFR: 8346664: C2: Optimize mask check with constant offset [v9]

[Matthias Ernst]

On Thu, 30 Jan 2025 14:19:13 GMT, Matthias Ernst <duke at openjdk.org> wrote:

>> Fixes [JDK-8346664](https://bugs.openjdk.org/browse/JDK-8346664): extends the optimization of masked sums introduced in #6697 to cover constant values, which currently break the optimization.
>> 
>> Such constant values arise in an expression of the following form, for example from `MemorySegmentImpl#isAlignedForElement`:
>> 
>> 
>> (base + (index + 1) << 8) & 255
>> => MulNode
>> (base + (index << 8 + 256)) & 255
>> => AddNode
>> ((base + index << 8) + 256) & 255
>> 
>> 
>> Currently, `256` is not being recognized as a shifted value. This PR enables further reduction:
>> 
>> 
>> ((base + index << 8) + 256) & 255
>> => MulNode (this PR)
>> (base + index << 8) & 255
>> => MulNode (PR #6697)
>> base & 255 (loop invariant)
>> 
>> 
>> Implementation notes:
>> * I verified that the originating issue "scaled varhandle indexed with i+1"  (https://mail.openjdk.org/pipermail/panama-dev/2024-December/020835.html) is resolved with this PR.
>> * ~in order to stay with the flow of the current implementation, I refrained from solving general (const & mask)==0 cases, but only those where const == _ << shift.~
>> * ~I modified existing test cases adding/subtracting from the index var (which would fail with current C2). Let me know if would like to see separate cases for these.~
>
> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestEquivalentInvariants: split scenarios that differ by 'AlignVector'
>   
>   Three variants (3d 3d2 3e) start vectorizing with -XX:-AlignVector, whereas they remain unvectorized under -XX:+AlignVector. Constrain these to AlignVector=false, and add 3 new variants (suffix 'a') with AlignVector=true.
>   
>   Special attention to 3e: it says
>       // Should never vectorize, since i1 and i2 are not guaranteed to be adjacent
>       // invar2 + invar3 could overflow, and the address be valid with and without overflow.
>       // So both addresses are valid, and not adjacent.
>   but now it does vectorize.

test/hotspot/jtreg/compiler/loopopts/superword/TestEquivalentInvariants.java line 831:

> 829:     // Should never vectorize, since i1 and i2 are not guaranteed to be adjacent
> 830:     // invar2 + invar3 could overflow, and the address be valid with and without overflow.
> 831:     // So both addresses are valid, and not adjacent.

This needs extra attention: it _does_ vectorize with `applyIf = {"AlignVector", "false"}`, so something is off.

test/hotspot/jtreg/compiler/loopopts/superword/TestEquivalentInvariants.java line 831:

> 829:     // Should never vectorize, since i1 and i2 are not guaranteed to be adjacent
> 830:     // invar2 + invar3 could overflow, and the address be valid with and without overflow.
> 831:     // So both addresses are valid, and not adjacent.

This needs extra attention: it _does_ vectorize with `applyIf = {"AlignVector", "false"}`, so something is off.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22856#discussion_r1935721509
PR Review Comment: https://git.openjdk.org/jdk/pull/22856#discussion_r1935721830