RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v7]
Quan Anh Mai
qamai at openjdk.org
Mon Dec 9 13:58:41 UTC 2024
On Mon, 9 Dec 2024 13:47:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>>
>> address reviews
>
> Ok, looks better.
>
> I've thought about this a little. And I am wondering if we cannot make the use of Rearrange generally easier.
>
> What if we want to use the `VectorRearrangeNode` elsewhere?
> One would assume that one could just check
> `arch_supports_vector(Op_VectorRearrange, ...elem_bt)`
> And then one could emit a `VectorRearrangeNode` for the given `elem_bt`. But that is not the case, the user would have to also check for `Matcher::vector_rearrange_requires_load_shuffle(shuffle_bt, num_elem)`, and possibly add a `VectorLoadShuffleNode`.
> I don't like this - it makes the use quite cumbersome.
>
> I have an idea for an alternative:
> You add a `VectorRearrangeNode::Ideal`, which then transforms itself if we have `Matcher::vector_rearrange_requires_load_shuffle`.
>
> I have not thought this through to the end, but it just seems it would be easier to use Rearrange in the future this way. But maybe we know that we will never use Rearrange in any other way, then I'm fine with this implementation. What do you think @PaulSandoz ?
@eme64 Yes I have thought about that. My idea is that once phase lowering is ready we will move the expansion there (#21599) . This removes the need to have a standalone method that checks if `LoadShuffleNode` is needed. The current situation is that `VectorRearrangeNode` is expected to come with `VectorLoadShuffleNode` so you cannot easily work with `VectorRearrangeNode`, either.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2528023981
More information about the hotspot-compiler-dev
mailing list