[PATCH] D70942: [LegalizeTypes] Bugfixes for big-endian targets when handling BITCASTs

[Eli Friedman via Phabricator via llvm-commits]

efriedma accepted this revision.
efriedma marked 3 inline comments as done.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM.  (Left some notes on the testcase if anyone else wants to follow.)



================
Comment at: llvm/test/CodeGen/ARM/legalize-bitcast.ll:21
 ; CHECK-NEXT:    vmov.f64 d19, d17
 ; CHECK-NEXT:    vstmia sp, {d18, d19} @ 16-byte Spill
 ; CHECK-NEXT:    b .LBB0_1
----------------
We split the load into two parts, so we don't read past the end.  For the first 64 bits, we load it as <8 x i8>, then bitcast it to `<4 x i16>` (using vrev).  For the last 32 bits, we load it as i32, then swap the high and low halves.  Then we concatenate the two, and spill to a stack slot as a native `<8 x i16>`.


================
Comment at: llvm/test/CodeGen/ARM/legalize-bitcast.ll:25
 ; CHECK-NEXT:    vldmia sp, {d16, d17} @ 16-byte Reload
 ; CHECK-NEXT:    vrev32.16 q9, q8
 ; CHECK-NEXT:    @ kill: def $d19 killed $d19 killed $q9
----------------
The vrev32.16 essentially bitcasts the `<8 x i16>` to `<4 x i32>`.  Then we extract the third element of the vector.  This corresponds to the scalar load in the first block, i.e. the last 4 bytes of the load.  Looks correct.


================
Comment at: llvm/test/CodeGen/ARM/legalize-bitcast.ll:47
+; CHECK-NEXT:    lsl r0, r0, #16
+; CHECK-NEXT:    orr r0, r0, r1, lsr #16
+; CHECK-NEXT:    @ implicit-def: $d16
----------------
So the value we want to return here is the first two bytes, if the i80 were stored in memory.  On a big-endian target, that's the two most significant bytes.  With LLVM's default calling convention, those bytes end up in the low bits of r0.  (This took me a little while to figure out; it would probably be easier to understand if the i80 value was loaded from memory, instead of passed in registers.)

The sequence here is that we shift r0 left 16 bits, move it to d16, move that to d18, "shift" the value right 16 bits using vrev, them move it back to r0.  That seems correct.


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

https://reviews.llvm.org/D70942