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

Dan Weber via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 2 20:19:20 PDT 2020


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) {
----------------
dweber wrote:
> dweber wrote:
> > 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. 
> > 
> > 
> (the above byte_swap on a little endian machine will always produce the original parameter without fail).
Two byte swaps would definitely be safe though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88591



More information about the llvm-commits mailing list