Reduced MaxVectorSize and vector type initialization

[Rohit Arul Raj]

Hello Vladimir,

We are fine with the current settings.

Thanks,
Rohit

On Thu, Oct 26, 2017 at 11:06 PM, Vladimir Kozlov <
vladimir.kozlov at oracle.com> wrote:

> Thank you, Rohit
>
> Do you plan to propose changes to increase vector size to 32 for 15h and
> 16h? Or AMD is fine with current settings?
>
> Thanks,
> Vladimir
>
> On 10/25/17 9:48 PM, Rohit Arul Raj wrote:
>
>> Hello Vladimir,
>>
>>
>> Please find the requested details:
>>
>>
>> AVX/AVX2 support availability on AMD Processors:
>>
>> Family 14h and earlier – No AVX support
>>
>> Family 15h -  (1^st -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 -  (4^th -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 <mailto: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 <mailto:
>> 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/
>>             <http://cr.openjdk.java.net/~neliasso/maxvectorsize/webrev/>
>>
>>             Feedback appreciated,
>>
>>             Regards,
>>             Nils Eliasson
>>
>>
>>
>>
>>
>>             http://cr.openjdk.java.net/~neliasso/maxvectorsize/webrev/
>>             <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/20171027/09631087/attachment-0001.html>