RFR: 8264104: Eliminate unnecessary vector mask conversion during VectorUnbox for floating point VectorMask [v4]
Jatin Bhateja
jbhateja at openjdk.java.net
Tue Apr 13 10:54:02 UTC 2021
On Tue, 13 Apr 2021 03:21:21 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:
>> The Vector API defines different element types for floating point VectorMask. For example, the bitwise related APIs use "`long/int`", while data related APIs use "`double/float`". This makes some optimizations that based on the type checking cannot work well.
>>
>> For example, the VectorBox/Unbox elimination like `"VectorUnbox (VectorBox v) ==> v"` requires the types of output and
>> input are equal. Normally this is necessary. However, due to the different element type for floating point VectorMask with the same species, the VectorBox/Unbox pattern is optimized to:
>>
>> VectorLoadMask (VectorStoreMask vmask)
>>
>> Actually the types can be treated as the same one for such cases. And considering the vector mask representation is the same for
>> vectors with the same element size and vector length, it's safe to do the optimization:
>>
>> VectorLoadMask (VectorStoreMask vmask) ==> vmask
>>
>> The same issue exists for GVN which is based on the type of a node. Making the mask node's` hash()/cmp()` methods depends on the element size instead of the element type can fix it.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>
> Use "Matcher::match_rule_supported_vector" for vector nodes checking
src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 861:
> 859: instruct vmaskcast(vReg dst) %{
> 860: predicate(UseSVE > 0);
> 861: match(Set dst (VectorMaskCast dst));
A strict check based on in-type and out-type in predicate could strengthen the pattern.
src/hotspot/share/opto/vectornode.hpp line 1240:
> 1238: };
> 1239:
> 1240: class VectorMaskCastNode : public VectorNode {
VectorMaskReinterpret seems better choice, since its a re-interpretation and not a casting (up/down).
-------------
PR: https://git.openjdk.java.net/jdk/pull/3238
More information about the hotspot-compiler-dev
mailing list