[PATCH] D45204: [X86][MIPS][ARM] New machine instruction property 'isMoveReg'

[Nikola Prica via Phabricator via llvm-commits]

NikolaPrica added a comment.

In https://reviews.llvm.org/D45204#1066331, @kparzysz wrote:

> Wouldn't it be better to have this as a TII hook?  There are instructions like "or reg, 0" or "add reg, 0" that are effectively copies, but only with specific operands.


There is already such hook for some mips and arm instructions like that.



================
Comment at: lib/Target/ARM/ARMInstrVFP.td:1027
+let isMoveReg = 1 in {
 def VMOVRS : AVConv2I<0b11100001, 0b1010,
                       (outs GPR:$Rt), (ins SPR:$Sn),
----------------
efriedma wrote:
> NikolaPrica wrote:
> > efriedma wrote:
> > > NikolaPrica wrote:
> > > > efriedma wrote:
> > > > > We usually use VMOVRRD (which moves two 32-bit integers into one 64-bit register) rather than VMOVRS; is there some way you can treat that as a "copy"?
> > > > There is similar instruction for MIPS that I've covered. On MIPS architecture similar instruction is used to transfer function arguments that were previously held in 32-bit register but for purpouse of call are transfered into 64-bit.  I think that it should be treated as copy?
> > > Not sure how the target-independent code will understand the semantics for a "move" with multiple inputs, but I'll let you figure that out, I guess.
> > In following patch new destination register is recognized as one that is marked as <def> and the source register is recognized only if it is marked as <killed>. Do you think that this will be enough?
> The issue with vmovrrd in particular is that there are multiple source registers; the current patch in D44016 only looks for one of them.
Oh. I've looked closer now. That could be a problem. Currently I'm not sure how to handle this in proper general way. It might be best to leave this as FIXME in ARMBaseInfo::isCopyInstr and untagg VMOVRRD since this is sort of a corner case?


https://reviews.llvm.org/D45204