This is an archive of the discontinued LLVM Phabricator instance.

AArch64: bitcast ops for i128 on big endian
Needs ReviewPublic

Authored by cpirker on Apr 7 2014, 2:55 AM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

Hi All,

This patch enables the big endian data order for BITCAST operations from i128 to vector types and vice versa.
Please review.

Thanks,
Christian

Diff Detail

Event Timeline

Hi Amara,

can you please review.

Thanks,
Christian

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.