RFR: 8286941: Add mask IR for partial vector operations for ARM SVE [v3]

Xiaohong Gong xgong at openjdk.org
Mon Jun 20 03:31:44 UTC 2022


On Mon, 20 Jun 2022 03:12:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> BTW, the max vector size used here should be referenced from the hardware supported max vector size, which should be `MaxVectorSize` for SVE. For those vectors whose vector size is `SuperWordMaxVectorSize`, but smaller than the hardware supported max size, we still need to generate a predicate for them to make sure the results are right. So using `MaxVectorSize` is necessary here.
>
> VectorNode::try_to_gen_masked_vector is a common routine which will get called during idealization of all the child vector nodes (generated either by autovectorizer or vectorAPI) unless child overrides its ideal routine.
> 
> Will this not result into out of memory writes for storeVector since autovectorizer works under influence of SuperWordMaxVectorSize which could be less than MaxVecotSize but your mask computation is  only considering MaxVectorSize, hence may generate wider masks than desired.

The mask is generated based on the real vector length, which guarantees only the vector lanes that inside of its valid vector length will do the operations. Higher lanes do nothing. So if a VectorStore has a vector length which equals to `SuperWordMaxVectorSize`, but the MaxVectorSize is larger than the `SuperWordMaxVectorSize`, a mask will be generated based on the real length `SuperWordMaxVectorSize`. And only lanes under the `SuperWordMaxVectorSize` will be stored. So I cannot see the influence on the out of memory issue. Could you please give an example apart of x86 cases? Thanks so much!  

BTW, I think flag `SuperWordMaxVectorSize`  should be equal to `MaxVectorSize` by default for other platforms instead of 64. If a platform (liken SVE) supports >64 bytes max vector size for auto-vectorization, it can only generate the vectors with 64 bytes vector size. This seems unreasonable. So do you have any plan refactoring this flag, or removing the usages for it in future? Thanks!

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

PR: https://git.openjdk.org/jdk/pull/9037


More information about the hotspot-compiler-dev mailing list