RFR: 8287697: Limit auto vectorization to 32-byte vector on Cascade Lake [v2]

[Vladimir Kozlov]

On Wed, 1 Jun 2022 23:57:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don’t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into maxvector
>  - x86 build fix
>  - Fix 32-bit build
>  - review comment resolution
>  - Change option name and add checks
>  - Limit auto vectorization to 32 byte vector on Cascade Lake

I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.

That may be preferable "simple fix" vs suggested changes for "short term solution".

The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.

BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8877