RFR: 8325520: Vector loads with offsets incorrectly compiled [v4]

Damon Fenacci dfenacci at openjdk.org
Mon May 6 08:16:57 UTC 2024


On Thu, 25 Apr 2024 12:39:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> // Load a float vector from the memory segment (internally, it does checkIndex and unsafe load from the byte array)
> FloatVector floatVector = FloatVector.fromMemorySegment(ms, offset, ByteOrder.nativeOrder())
> ```
> 
> I did not test this, but I think something like this should work.

Right! I totally missed that `from`- `intoMmemorySegment` methods! I guess that’s probably one reason why vector nodes are not typed.
I’ve added checks to `StoreNode::Identity` as well.

> src/hotspot/share/opto/memnode.cpp line 3533:
> 
>> 3531:       const Node* offsets = stv->in(StoreVectorScatterMaskedNode::Offsets);
>> 3532:       const Node* mask = stv->in(StoreVectorScatterMaskedNode::Mask);
>> 3533:       if (mem->is_StoreVectorScatterMasked()) {
> 
> This `if` will always be true, since we already check `mem->Opcode() == Opcode()`. The code would be simpler if you extracted the offsets and masks in parallel.

Yep, I removed this useless `if` and 2 other terms in the ifs before that. I'm just not sure of what you mean with
> if you extracted the offsets and masks in parallel.

> src/hotspot/share/opto/vectornode.hpp line 916:
> 
>> 914:   virtual int store_Opcode() const {
>> 915:     // Ensure it is different from any store opcode
>> 916:     return Op_LoadVectorGather;
> 
> I think you should take `-1`, which is what `MemNode::store_Opcode()` returns. It means "unknown".

OK. I was just a bit concerned that a check for equality between 2 `store_Opcode` could be true because they are both -1 but this shouldn’t happen. Changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18347#issuecomment-2095424211
PR Review Comment: https://git.openjdk.org/jdk/pull/18347#discussion_r1590680121
PR Review Comment: https://git.openjdk.org/jdk/pull/18347#discussion_r1590679021


More information about the hotspot-compiler-dev mailing list