RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules

[Hao Sun]

On Mon, 4 Jul 2022 12:51:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Aha! I was looking forward to this.
>> 
>> On 7/1/22 11:46, Hao Sun wrote:
>>  > Note-1: m4 file is not introduced because many duplications are highly
>>  > reduced now.
>> 
>> Yes, but there's still a lot of duplications. I'll make a few examples
>> of where you should make simple changes that will usefully increase the
>> level of abstraction. That will be a start.
>
>> @theRealAph Thanks for your comment. Yes. There are still duplicate code. I can easily list several ones, such as the reduce-and/or/xor, vector shift ops and several reg with imm rules. We're open to keep m4 file.
>> 
>> But I would suggest that we may put our attention firstly on 1) our implementation on generic vector registers and 2) the merged rules (in particular those we share the codegen for NEON only platform and 128-bit vector ops on SVE platform). After that we may discuss whether to use m4 file and how to implement it if needed.
> 
> We can do both: there's no sense in which one excludes the other, and we have time.
> 
> However, just putting aside for a moment the lack of useful abstraction mechanisms, I note that there's a lot of code like this:
> 
> 
>     if (length_in_bytes <= 16) {
>       // ... Neon
>     } else {
>       assert(UseSVE > 0, "must be sve");
>       // ... SVE
>     }
> 
> 
> which is to say, there's an implicit assumption that if an operation can be done with Neon it will be, and SVE will only be used if not. What is the justification for that assumption?

@theRealAph @adinn 
Thanks for your reviews!
I have updated the patch based on the review comments. Would you mind taking another look? Thanks!

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

PR: https://git.openjdk.org/jdk/pull/9346