[PATCH] D88591: [WebAssembly] Emulate v128.const efficiently

[Dan Weber via Phabricator via llvm-commits]

dweber added inline comments.


================
Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1631
+    Result = DAG.getSplatBuildVector(MVT::v2i64, DL,
+                                     DAG.getConstant(Splatted, DL, MVT::i64));
+    if (!FirstHalfSufficient && !SecondHalfSufficient && !CombinedSufficient) {
----------------
hubert.reinterpretcast wrote:
> dweber wrote:
> > hubert.reinterpretcast wrote:
> > > `Splatted` represents a different value on big endian systems at this point.
> > @hubert.reinterpretcast If you remove the byte_swap function all together, do you still get the same issue? 
> I mean, from code inspection, without needing to assume anything weird on the original `byte_swap`.
> 
> Using half the width as an example (4 elements of 16 bits):
> Values:
> ```
> 0x1234 0x5678 0x1234 0x5678
> ```
> 
> Resulting bytes in storage:
> ```
> 0x34 0x12 0x78 0x56 // 0x34 0x12 0x78 0x56
> 0xff 0xff 0xff 0xff // 0xff 0xff 0xff 0xff
> ```
> 
> Request constant from value with bytes:
> ```
> 0x34 0x12 0x78 0x56
> ```
> i.e., on little endian systems, request constant with value:
> ```
> 0x56781234
> ```
> or, on big endian systems, request constant with value:
> ```
> 0x34127856
> ```
@hubert.reinterpretcast the reason I ask is because webassembly assumes little endian. On big endian machines, the constant could have been converted before we do anything here -- especially since the developer using emscripten is taught there is no other byte order but little endian. If that's the case, the byte swap could be creating the problem. 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88591