[LLVMdev] help: about how to use tblgen to constraint operand.

Evan Cheng echeng at apple.com
Thu Feb 19 09:11:50 PST 2009


Currently there is no constraint that tells the register allocator to  
allocate a consecutive register pair. What I would suggest you do is  
to declare pseudo register pair registers (and corresponding register  
class, say PAIR_GPR). In this case, your myFMDRR would take one input  
of PAIR_GPR class. The asm printer should be taught to print a  
PAIR_GPR register as two GPR registers (you should also teach the JIT  
of the same thing).

A PAIR_GPR register should be a super register of two GPR registers.  
e.g. r0r1_pair is a super register of r0 and r1. In order to  
*construct* a PAIR_GPR register, you have to use two INSERT_SUBREG. To  
extract out a GPR from a PAIR_GPR, you need to issue EXTRACT_SUBREG.  
In most cases, these will be nop's. In other cases, they are copies.

Evan

On Feb 19, 2009, at 2:00 AM, 任坤 wrote:

> I define a pattern to move two 32bits gpr to 64bits fpr. like arm  
> instructure fmdrr.
> But I need to use an even/odd register pair to save its 2 operands.
> I define in mytarget.td:
>
> myfmdrr:
> SDTypeProfile<1, 2, [SDTCisVT<0, f64>, SDTCisVT<1, i32>,
>     SDTCisSameAs<1, 2>]>;
> def my_fmdrr : ...........
> def myFMDRR : ....
>                       (outs FPR: $result), ins(GPR: $op1, GPR:$op2 )
>                        [(setFPR: $result, (my_fmdrr GPR: $op1, GPR: 
> $op2) )]
>
> I create myfmdrr instructure in mytargetISelLowering.cpp. and its  
> operands are in R0 and R1.
> But after optimization, the operands are save R2 and R1. I know  
> optimization pass does not
> know myfmdrr operands constraint. But How I tell optimzition pass by  
> tblgen??
>
> Could I can control operand constraint in mytargetiSelLowering.cpp?  
> How do I control??
>
>
> 好玩贺卡等你发,邮箱贺卡全新上线! 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090219/ba38a9af/attachment.html>


More information about the llvm-dev mailing list