RFR: 8342662: C2: Add new phase for backend-specific lowering [v6]

Vladimir Ivanov vlivanov at openjdk.org
Thu Mar 27 01:01:32 UTC 2025


On Thu, 27 Mar 2025 00:25:14 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I struggle to understand what are you expecting right now.

I'm encouraging some experiments to justify proposed design. 

Do you suggest to take the patch for granted and then think through all the consequences later? I hope not.

>> From Vector API perspective, it's still a huge win since it eliminates vector boxing/unboxing
> Not if the cost of extracting and inserting elements is large since we are doing a lot of them here.

It's still cheaper than boxing/unboxing and iterating over in-memory representation. (FTR 512-bit vector of longs/doubles has 8 elements.)

> And even if we can do it in all platforms, I don't see why we can't start with one architecture and expand the transformation to the others later. The function that does the transformation can be put in an arch-independent file that is called from lowering in an arch-dependent file.

Simply because there are better ways to solve that particular problem. (IMO post-loop opts IGVN and `Matcher::match_rule_supported_vector()` enable cleaner implementation.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21599#issuecomment-2756108334
PR Comment: https://git.openjdk.org/jdk/pull/21599#issuecomment-2756110229


More information about the hotspot-compiler-dev mailing list