Reduced MaxVectorSize and vector type initialization

[Nils Eliasson]

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/b33a2d8e/attachment.html>