[PATCH] D94708: [IR] Introduce llvm.experimental.vector.splice intrinsic

[Bin Cheng via Phabricator via llvm-commits]

bin.cheng-ali added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:8623
+  //    Ptr = Ptr + (Imm * sizeof(VT.Elt))
+  //  Res = Load Ptr
+
----------------
paulwalker-arm wrote:
> bin.cheng-ali wrote:
> > Sorry for may stupid question, this stores two vector register and load in the middle, does Endingness matters here?  How does LLVM make sure correct sequence of elements is loaded?  Thanks in advance.
> There's no such thing as a stupid question :)
> 
> These are load/store operations on vector types so endianness only plays a role in how each element is stored and not in the order of the elements.  That's to say, element N will be at the same location in memory regardless of endianness, however, the bytes that make up element N will be laid out differently.  The index used to splice the vectors is also element based, which means there are no partial element accesses and thus no endianness issues.
Thanks very much for explanation.  I assume this is defined in Arm architecture reference manual, however, I noticed there is supplement rule for SVE as:
For unpredicated SVE vector register loads and stores, the vector is treated as containing byte elements that
are transferred in increasing element number order without any endianness conversion.

IIUC, this rule would apply here?  Of course no endianness issue either way.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94708/new/

https://reviews.llvm.org/D94708