RFR: 8325520: Vector loads with offsets incorrectly compiled [v6]
Damon Fenacci
dfenacci at openjdk.org
Tue May 7 15:31:56 UTC 2024
On Tue, 7 May 2024 12:42:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>> Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - JDK-8325520: add store/load masked vector tests
>> - JDK-8325520: add store/load tests with duplicate offsets
>
> src/hotspot/share/opto/memnode.cpp line 3554:
>
>> 3552: }
>> 3553: }
>> 3554: }
>
> I think the code is now correct.
> But I find the nested if-elseif-elseif-else ... structure a bit hard to read. And there is quite some code duplication (e.g. `result = mem` and all the `eqv_uncast` checks).
>
> You could either do something like this:
>
> if (!is_StoreVector() ||
> as_StoreVector()->has_same_vect_type_and_offsets_and_mask(mem->as_StoreVector())) {
> result = mem;
> }
>
>
> Sketch:
>
> has_same_vect_type_and_offsets_and_mask:
>
> different vect_type -> return false
> ...
>
>
> Or maybe it would be better to define virtual functions to get the `mask` and `offsets` from a `StoreVector`? If it has none, just return `nullptr`. Sometimes people worry about virtual methods, but we already use them extensively for the node Value/Ideal anyway.
>
> Then, you can do:
>
> if (!is_StoreVector()) {
> result = mem;
> } else {
> const Node* offsets1 = as_StoreVector()->get_offsets();
> const Node* offsets2 = mem->as_StoreVector()->get_offsets();
> const Node* mask1 = as_StoreVector()->get_mask();
> const Node* mask2 = mem->as_StoreVector()->get_mask();
> if (offsets1->eqv_uncast(offsets2) && offsets1->eqv_uncast(offsets2)) {
> result = mem;
> }
> }
>
> I think that would be the cleanest and most readable way.
>
> What do you think?
I agree that it is quite convoluted probably also because I've put `if (!is_StoreVector())` (which is redundant) at the beginning to get the most common case out of the way but still...
At first I thought that multiple inheritance would be a good solution (masks and offsets could be inherited by the corresponding nodes) but the "HotSpot Coding Style" clearly says to avoid it...
So, I think in the end your second suggestion is the cleanest. Changing it...
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18347#discussion_r1592686165
More information about the hotspot-compiler-dev
mailing list