Reduced MaxVectorSize and vector type initialization

[dean.long at oracle.com]

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/20171018/5eb002d7/attachment-0001.html>