search for: movrr

...dicate) at index 3273, continuing at 3284 Skipped scope entry (due to false predicate) at index 3285, continuing at 3305 Match failed at index 3259 Continuing at 3306 Match failed at index 3307 Continuing at 3327 Match failed at index 3328 Continuing at 3361 Morphed node: t17: i32 = MOVRR t17 ISEL: Match complete! Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190209/e46a9dea/attachment.html>

....addImm(-UNITS_PER_WORD).addReg(ARC::BLINK); } // Save the caller's frame pointer (if required), and set new FP to this // location. BuildMI(MBB, MBBI, dl, TII.get(ARC::STrri_a)).addReg(ARC::SP) .addImm(-UNITS_PER_WORD).addReg(ARC::FP); BuildMI(MBB, MBBI, dl, TII.get(ARC::MOVrr), ARC::FP).addReg(ARC::SP); ... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121026/8f1f3bfa/attachment.html>

...pcode, but otherwise it does not affect anything except for constraints on the sizes of operands. And constraint is basically that the size of both operands should be the same. Wouldn't it be possible and even more clean to have just one description like (I use a pseudo-description here): def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, (i8mem|i16mem|i32mem):$src), "mov{b} {$src, $dst|$dst, $src}", []>, isSameSize($dst, $src); The semantic of such a description would mean that $dst should be one of GR8, GR16, GR32 and $dst is one of i8mem, i16mem,...

...re I am working with supports moving values directly from one register to another, or moving an immediate straight to a register, and I cannot figure out how to do this in LLVM. I originally tried matching something like [(set RegisterClass:$dest, RegisterClass:$src)] in my TargetInstrInfo.td: def MOVrr : MyInstrClass<(outs CPURegs:$dest), (ins CPURegs:$src), "mov $dest,$src", [(set CPURegs:$dest, CPURegs:$src)]>; However this matches very random inputs - such as (set RegisterClass:$dest, (or RegisterClass:$src1, RegisterClass:$src2)), which is just strange - and is obviously no...

I have just added a retflag to the ARM backend. I thought that using BRIND directly was to blame for a dummy move. But I the move wasn't removed. When compiling --------------------------------------- int %g() { entry: call void %f( ) ret int 42 } declare void %f() -------------------------------------- The ARM backend produces ------------------------------------------- g:

...ffect anything except for constraints on the sizes of > operands. And constraint is basically that the size of both operands > should be the same. Ok. > Wouldn't it be possible and even more clean to have just one > description like (I use a pseudo-description here): > > def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, > (i8mem|i16mem|i32mem):$src), > "mov{b} {$src, $dst|$dst, $src}", []>, isSameSize($dst, > $src); We already have something like this, but it's a little more general. The X86 backend hasn't been co...

...n the sizes of >> operands. And constraint is basically that the size of both operands >> should be the same. > > Ok. > >> Wouldn't it be possible and even more clean to have just one >> description like (I use a pseudo-description here): >> >> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >> (i8mem|i16mem|i32mem):$src), >> "mov{b} {$src, $dst|$dst, $src}", []>, isSameSize($dst, >> $src); > > We already have something like this, but it's a little more general. The > X86...

On Mon, 2 Oct 2006, Roman Levenstein wrote: >>> Wouldn't it be possible and even more clean to have just one >>> description like (I use a pseudo-description here): >>> >>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >>> (i8mem|i16mem|i32mem):$src), >>> "mov{b} {$src, $dst|$dst, $src}", []>, > isSameSize($dst, >>> $src); >> >> We already have something like this, but it's a little more...

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really