RFR: 8351645: C2: Assertion failures in Expand/CompressBits idealizations with TOP

[Jatin Bhateja]

On Wed, 11 Jun 2025 09:32:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Bugfix patch adds missing safe type access checks in Expand/Compress Ideal transforms. Problem occues during IGVN cleanups after partial peeling of loop.
>> 
>> Test mentioned in the bug report has been included along with the patch.
>> 
>> Kindly review.
>> 
>> Best Regards,
>> Jatin
>
> Root Cause:  Problem occurs during IGVN cleanup after partial peeling.
> 
> Partial peeling rotates the loop by bringing out the peel section and creating a new loop which begins with the non-peel section, followed by the peel section loop back.
>  
> To perform this translation, the compiler begins by cloning the original loop, brings the peel section into the new loop header, re-wires the new header to point to the start of the non-peel block (cut-point) of new loop and then stitches peel section of the cloned loop after non-peel section thereby rotating the original loop.  Since the peel-section is the only usable part of the cloned loop hence all remaining part of the loop is swiped out by GVN cleanup.
> 
> In this case, during cleanups when the control reaches the ExpandBits/CompressBits idealization, it hits upon an unsafe use (is_* call) of mask input, which was tied to TOP node and results into an assertion failure,  to fix the problem this PR adds safe isa_* call before unsafe accesses. 
> 
> With default options, the problem only occurs with Long Expand/CompressBits because for integer variants, nodes get picked up in a different order from the IGVN worklist;  we can use -XX:+StressIGVN to reproduce the issue with integral variants.

> @jatin-bhateja Thanks for adding me as a contributor! I'll run some testing now.
> 
> Could you change the title to also include `compress`? Suggestion: `C2: handle TOP in Expand/CompressBitsNode::Ideal`

Hi @eme64 , let me know if its good to land.

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

PR Comment: https://git.openjdk.org/jdk/pull/25586#issuecomment-2969860982