[PATCH] [AArch64 - BE] BUILD_VECTOR lane order is reversed in big-endian mode

Tim Northover t.p.northover at gmail.com
Fri Aug 29 23:25:43 PDT 2014

> AFAICS the REV instructions are redundant (in the MOVI case). My understanding was that we have to perform the lane reversal within resolveBuildVector() because at the callee end (when a vector is passed to a function) we get something like:

Ah, if you're looking at the call case specifically then some kind of
rev is needed for ABI compatibility, but what we're emitting at the
moment is a merged version of the necessary REV and the dodgy one.
When passing a v4i16 emit:

    REV64 v0.2s, v0.2s

However, the DAG that actually gets created is closer to:

    REV32 v0.4h, v0.4h // By the code associated with resolveBuildVector
    REV64 v0.4h, v0.4h // By LowerCall

And the combination of those two operations is indeed a "REV64
v0.2s"[1]. I think that first one is a problem (particularly in the
BIC/OR case, but conceptually not what we want even for MOVI).



[1] A good way to do these in your head is that the bigger size always
gets attached to the REV mnemonic, and combining two REVs with a
common size ("16" in this case) you drop that common size. So we have
64 <-> 16 and 32 <-> 16, which means the result is a 32 <-> 64,
written REV64 v0.2s.

More information about the llvm-commits mailing list