[PATCH] AArch64: bitcast ops for i128 on big endian

Tim Northover t.p.northover at gmail.com
Fri Apr 11 00:48:27 PDT 2014


  Hi Christian,

  I think this is another one that's barking up the wrong tree. The existing DAG looks correct to me and what probably needs implementing here (and quite possibly for your constant pool issue too, though I can't be sure until I see a more complete source) is the lane remapping during ISel that me, Albrecht & Jiangning discussed in the other large thread.

  My idea for an implementation is that any pattern dealing with vector indices should use an operand (currently "neon_uimm2_bare" and so on) that applies an SDNodeXForm which reverses the lane actually chosen. The basic idea is that LLVM's indices refer to the lowest addressed element, but because of how we've loaded & stored vectors these elements are actually in "MaxLanes - index" of the register.

  Some modification to the existing classes along the lines of:

      def BE_Reverse_4Lanes : SDNodeXForm<imm, [{
        if (Subtarget->isLittle()) return SDValue(N, 0);
        return CurDAG->getTargetConstant(4 - N->getZExtValue(), MVT::i64);
      }]>;

      def neon_uimm2_bare : Operand<i64>,
                              ImmLeaf<i64, [{return Imm < 4;}], BE_Reverse_4Lanes> {
        let ParserMatchClass = neon_uimm2_asmoperand;
        let PrintMethod = "printUImmBareOperand";
      }

  seems to do the trick for me (and should make LD1LN instructions and lots of other things work as expected too). I'm *hoping* this and the LD1/LDR changes are all that will be needed in the backend.

  Cheers.

  Tim.

http://reviews.llvm.org/D3306






More information about the llvm-commits mailing list