Reduced MaxVectorSize and vector type initialization

[Rohit Arul Raj]

Hello Vladimir,


Please find the requested details:


AVX/AVX2 support availability on AMD Processors:

Family 14h and earlier – No AVX support

Family 15h -  (1st-gen), (2nd-gen), (3rd-gen) AVX support available, max
vector width is 32 bytes (we limit the vector size to 16 bytes in openJDK).

Family 16h – AVX support available, max vector width is 32 bytes (we limit
the vector size to 16 bytes in openJDK).

Family 15h -  (4th-gen) AVX, AVX2 support available, max vector width is 32
bytes (we limit the vector size to 16 bytes in openJDK).

Family 17h – AVX, AVX2 support available, max vector width is 32 bytes (our
proposed changes have vector size set to 32 bytes in openJDK).

AVX3 support is not available on AMD processors yet.

>From the comments below, Dean's suggestions seems reasonable.

Regards,
Rohit


On Wed, Oct 25, 2017 at 3:32 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> We can't use platform specific UseAVX flag in shared code in type.cpp.
>
> I would say we should not support AVX (set UseAVX to 0) on AMD < 17h.
> And we need to ask AMD which AMD cpus are supporting AVX, AVX2, AVX3 and
> corresponding vectors 32 and 64 bytes.
> If AMD's Instructions Set before 17h does not support whole 32 bytes
> vectors we can't call it AVX.
>
> Thanks,
> Vladimir
>
> On 10/18/17 10:01 AM, dean.long at oracle.com wrote:
>
>> How about initializing TypeVect::VECTY and friends unconditionally?  I am
>> nervous about exchanging one guarding condition for another.
>>
>> dl
>>
>>
>> On 10/18/17 1:03 AM, Nils Eliasson wrote:
>>
>>>
>>> HI,
>>>
>>> I ran into a problem with the interaction between MaxVectorSize and the
>>> UseAVX. For some AMD CPUs we limit the vector size to 16 because it gives
>>> the best performance.
>>>
>>> +    if (cpu_family() < 0x17 && MaxVectorSize > 16) {
>>>> +      // Limit vectors size to 16 bytes on AMD cpus < 17h.
>>>>        FLAG_SET_DEFAULT(MaxVectorSize, 16);
>>>>      }
>>>>
>>>
>>> Whenf MaxVecorSize is set to 16 it has the sideeffect that the
>>> TypeVect::VECTY and mreg2type[Op_VecY] won't be initalized even though the
>>> platform has the capability.
>>>
>>> Type.cpp:~660
>>>
>>> [...]
>>> >   if (Matcher::vector_size_supported(T_FLOAT,8)) {
>>> >     TypeVect::VECTY = TypeVect::make(T_FLOAT,8);
>>> >   }
>>> [...]
>>> >   mreg2type[Op_VecY] = TypeVect::VECTY;
>>>
>>>
>>> In the ad-files feature flags (UseAVX etc.) are used to control what
>>> rules should be matched if it has effects on specific vector registers.
>>> Here we have a mismatch.
>>>
>>> On a platform that supports AVX2 but have MaxVectorSize limited to 16,
>>> the VM will fail when the TypeVect::VECTY/mreg2type[Op_VecY] is
>>> uninitialized. We will also hit asserts in a few places like:
>>> assert(Matcher::vector_size_supported(T_FLOAT,RegMask::SlotsPerVecY),
>>> "sanity");
>>>
>>> Shouldn't the type initialization in type.cpp be dependent on feature
>>> flag (UseAVX etc.) instead of MaxVectorSize? (The type for the vector
>>> registers are initialized if the platform supports them, but they might not
>>> be used if MaxVectorSize is limited.)
>>>
>>> This is a patch that solves the problem, but I have not convinced myself
>>> that it is the right way:
>>> http://cr.openjdk.java.net/~neliasso/maxvectorsize/webrev/
>>>
>>> Feedback appreciated,
>>>
>>> Regards,
>>> Nils Eliasson
>>>
>>>
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~neliasso/maxvectorsize/webrev/
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20171026/944f40e6/attachment-0001.html>