RFR 8076276 support for AVX512

[Berg, Michael C]

Ok, I will leave that way it is plus the comment.

Thanks,
-Michael

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Thursday, May 07, 2015 4:33 PM
To: Berg, Michael C; Roland Westrelin
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR 8076276 support for AVX512

You should have said this from the beginning! Add comment to x86_32.ad before operand vecS explaining why it uses vectors_reg_legacy.

To avoid unneeded runtime code generation by adlc. It produces the same result regardless evex support for these vectors in 32-bit VM.

Thanks,
Vladimir

On 5/7/15 3:43 PM, Berg, Michael C wrote:
> Tried it out as a single definition referencing reg_class_dynamic for both 64-bit and 32-bit. On the new machine model it does work correctly for both.  However on 32-bit we will now emit more auto generated code through the adlc layer as we will have the same definitions on both evex and non evex, it is why I used separate definitions.
>
> -Michael
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, May 07, 2015 2:28 PM
> To: Berg, Michael C; Roland Westrelin
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR 8076276 support for AVX512
>
> On 5/7/15 2:07 PM, Berg, Michael C wrote:
>> Roland,
>>
>> VecS like the other forms of Vec{D|X|Y|Z} are defined as needed in each of the 32 and 64 ad files, as they are divergent now.  The 32-bit version only has the legacy bank.
>> 64-bit version uses the newly defined reg_class_dynamic definition to provide the appropriate bank of registers based on CPUID.  The chunk3 rename is an artifact of removing the kreg bank.
>
>
> For 32-bit reg_class_dynamic will give the same result as legacy because registers after XMM7 will be cut of by #ifdef _LP64. So I don't understand why you need to split Vec{D|X|Y} operands. You do kept vecZ operand the same for 32- and 64-bit.
>
> Regards,
> Vladimir
>
>> I will put it back to the old name (and test it out).  Eventually, we will change it back once we formalize the usage of kreg into all facets of code generation ( in a later patch ).
>> If we made a single version out of os_supports_avx_vectors()'s loop, we would have a guard in the loop as the size of the regions are now different, it seems cleaner the way it is.
>>
>> In x86.64.ad:
>>
>>>> 3463 // Float register operands
>>>> 3473 // Double register operands
>>
>> I will re-add the comments.
>>
>> In chaitain.hpp:
>>
>> 144   uint16_t _num_regs;            // 2 for Longs and Doubles, 1 for all else
>>
>> I will fix the comment location.
>>
>> Thanks,
>> Michael
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev
>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>> Roland Westrelin
>> Sent: Thursday, May 07, 2015 11:40 AM
>> To: Vladimir Kozlov
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR 8076276 support for AVX512
>>
>>>>> http://cr.openjdk.java.net/~kvn/8076276/webrev.02
>>>>
>>>> This looks good to me. A few minor remarks:
>>>>
>>>> Shouldn't the #ifdef _LP64 new instruct be in x86_64.ad? I see there are already other #ifdef _LP64 in x86.ad so I'm not sure what the guideline is.
>>>
>>> Why you need #ifdef _LP64 in x86_64.ad were _LP64 is set by default (used only in 64-bit VM)? What new instructions you are talking about?
>>
>> I'm talking about:
>> 4101 #ifdef _LP64
>> 4102 instruct rvadd2L_reduction_reg(rRegL dst, rRegL src1, vecX src2, 
>> regF tmp, regF tmp2) %{
>>
>> for instance in x86.ad
>> Why isn't it in x86_64.ad?
>>
>> Roland.
>>>
>>>>
>>>> In vm_version_x86.hpp, os_supports_avx_vectors(), you could have a single copy of the loop with different parameters.
>>>>
>>>> Not sure why you dropped:
>>>>
>>>> 3463 // Float register operands
>>>> 3473 // Double register operands
>>>>
>>>> in x86_64.ad
>>>>
>>>> In chaitin.hpp:
>>>>
>>>> 144   uint16_t _num_regs;            // 2 for Longs and Doubles, 1 for all else
>>>>
>>>> comment is not aligned with the one below anymore.
>>>>
>>>> Roland.
>>>>
>>>
>>> I also have questions to Michael.
>>>
>>> Why you renamed chunk2 to "alloc_class chunk3(RFLAGS);"?
>>>
>>> Why you moved "operand vecS() etc." from x86.ad ? Do you mean  evex is not supported in 32-bit?
>>>
>>> Thanks,
>>> Vladimir
>>