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

[Vladimir Kozlov]

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.

Thank you for checking stubs code.

We still have to run performance testing with this patch. We need only additional run with `MaxVectorSize=32` to compare results.

And I want @jatin-bhateja to approve this change too. Or give better suggestion.

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

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