[PATCH] D103808: [ARM] Generate VDUP(Const) from constant buildvectors

Simon Tatham via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 8 02:53:58 PDT 2021


simon_tatham accepted this revision.
simon_tatham added inline comments.
This revision is now accepted and ready to land.


================
Comment at: llvm/test/CodeGen/Thumb2/mve-vmovimm.ll:34
 ; CHECKBE:       @ %bb.0: @ %entry
-; CHECKBE-NEXT:    adr r0, .LCPI2_0
-; CHECKBE-NEXT:    vldrb.u8 q1, [r0]
-; CHECKBE-NEXT:    vrev64.8 q0, q1
+; CHECKBE-NEXT:    movw r0, #772
+; CHECKBE-NEXT:    movt r0, #258
----------------
I think this output is right, but it confused me completely for a while and I had to try it in emulation to convince myself!

In the middle of a larger function, I think that if you wanted to make this 1,2,3,4,1,2,3,4,... vector and then immediately apply another v16i8 operation to it, you would vdup the //same// 32-bit constant 0x04030201 regardless of endianness, because the logical 'lane 0' of the vector always occupies the low-order bits.

And the reason why the output is different between LE and BE in //this// context is that the vdup is immediately followed by a function return, which in BE requires an extra vrev due to the vector register PCS. And that function-return vrev has been folded into the constant, which is why it's the other way round here.

So, I think this //is// the right output, but it might benefit from a comment in case the next reader gets as confused as I did!


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

https://reviews.llvm.org/D103808



More information about the llvm-commits mailing list