NI_AdvSimd_Store* use of gtNewSimdStoreNode() about runtime HOT 5 OPEN

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

from runtime.

I think all Store-like operations were GT_HWINTRINSIC all the way in JIT untill recently we started to import some of them as GT_IND/GT_STOREIND so they can benefit from various general IND opts and even addressing modes (afair, it was @tannergooding). I guess NI_AdvSimd_StoreSelectedScalar can be also made to be so?

from runtime.

Right, we changed the standard loads/stores to use GT_IND/GT_STOREIND as a way to benefit from the plethora of existing optimizations around those GenTree kinds without negatively impacting throughput and needing to plumb support for hardware specific intrinsics.

In order for STOREIND to be used for StoreSelectedScalar, other more complex (MaskStore) or less common (StoreAligned) APIs, you would need to update STOREIND to be able to track the additional information required (various flags and potentially additional operands or state). The same would be true for using IND for various Load APIs.

from runtime.

For StoreSelectedScalar in particular, there's a place to track address (GenTreeIndir::Addr) and value (GenTreeStoreIndir::Data), but no place to track index.

You could transform it to StoreInd(addr, GetElement(value, index)) and then have specialized lowering handling to track the containment and then have codegen look for contained GetElement to allow emitting the correct instruction instead.

If you were to do that for Arm64, we'd want to also do similar x64 around the various Extract* APIs that achieve the same thing.

from runtime.

Thanks for the additional context @tannergooding . My initial thought was we are missing some correctness areas by not doing gtNewSimdStoreNode() but now I understand that it is more for performance reason.

from runtime.