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

[Sandhya Viswanathan]

On Thu, 2 Jun 2022 01:16:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 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.

@vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.

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

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