RFR: 8338023: Support two vector selectFrom API [v7]
Jatin Bhateja
jbhateja at openjdk.org
Fri Sep 6 18:13:35 UTC 2024
On Fri, 30 Aug 2024 14:57:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>> src/hotspot/share/opto/vectornode.cpp line 2183:
>>
>>> 2181: };
>>> 2182: // Targets emulating unsupported permutation for certain vector types
>>> 2183: // may need to message the indexes to match the users intent.
>>
>> Suggestion:
>>
>> // may need to massage the indexes to match the users intent.
>
> This optimization for now seems quite specific to your `SelectFromTwoVectorNode::Ideal` lowering code. Can this conversion not be done there already?
>
> What is the semantics of `VectorRearrangeNode`? Should its shuffle vector always be bytes, and we now violated that "for a quick second"? Or is it going to be generally the idea to create all sorts of shuffle types and then fix that up? But then why do we need the `vector_indexes_needs_massaging`?
>
> Can you help me understand the concept/strategy behind this?
Ok, IIRC variable index permutation instruction on every target expects shape conformance b/w data vector and permute index vector. Rearrange expects indices to be passed throug shuffle, idealization routines automatically injects a VectorLoadShuffle after loading indexes held in shuffle's backing storage i.e. a byte array.
In all the cases apart from byte vector permute , VectorLoadShuffle expands the index byte lanes to match the data vector lane. So we always end up emitting a lane expansion instruction before permute instruction (scenario 1). Apart from usual expansions VectorLoadShuffle may also do additional magic for some targets where it may need to prune / massage the index vector if target does not support destination vector type (scenario 2).
For our case, new selectFrom accepts the indices though vectors which save redundant expansions, but to leverage existing backend support for scenario 2 we do target specific pruning
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1747532612
More information about the hotspot-dev
mailing list