[PATCH] D35833: [globalisel][tablegen] Add support for importing 'imm' operands.
Daniel Sanders via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 3 06:13:09 PDT 2017
dsanders added inline comments.
================
Comment at: test/CodeGen/AArch64/GlobalISel/select-imm.mir:29
+
+ %0(s32) = G_CONSTANT i32 1234
+ %w0 = COPY %0(s32)
----------------
dsanders wrote:
> rovka wrote:
> > dsanders wrote:
> > > rovka wrote:
> > > > Nit: Maybe test a negative constant instead, to make sure we do the right extension?
> > > Done. This revealed that a small mistake was preventing my code from being executed. The GIM_CheckNumOperands was checking for 1 operand instead of 2 (because Src had no children). The test only passed because the C++ was catching it. I've fixed this and killed the C++ that was handling it. I've also fixed a bug this revealed where ADD8ri had higher priority than INC8r on X86
> > >
> > > This also turned up a small inconsistency between the old C++ and tablegen. The C++ uses ZExt but TableGen uses SExt. I haven't decided how to fix this one yet. For AArch64, I should presumably switch to ZExt but this is the wrong thing to do on some targets such as Mips where all register-width integers are signed.
> > Is there a reason why the old code would ZExt instead of SExt? SExt seems more natural in this context, but I admittedly haven't thought too much about it.
> I'm not sure at the moment. It could be that it makes no difference either way aside from targets like Mips which specifies the value of bits that don't physically exist in an implementation (values are theoretically sign-extended to infinite-width) and relies on this for 32-bit code to work correctly on a 64-bit CPU.
>
> One observation from the patches I've been working on this week is that ImmLeaf's sign-extend the constant internally so it would make sense for the same operator without any predicates (`imm`) to do the same. Unfortunately, that argument can be used the other way if you start from the PatFrag's which start with an SDNode and frequently zero-extend it.
SelectionDAG doesn't seem to extend at all for `imm` without predicates (it just morphs the node from ISD::Constant to `AArch64::MOVi32imm`, leaving the operands untouched) so I think it's safe to say it doesn't matter what we pick here.
Do you have a preference? If not, I'll stick with the zero-extend for now.
https://reviews.llvm.org/D35833
More information about the llvm-commits
mailing list