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

[Evan Cheng]

On Feb 19, 2009, at 8:26 PM, 任坤 wrote:

> hi, Dear Evan Cheng:
>
> My cpu is i32 embeded CPU. I define pseudo register pair registers.
>
> In mytargetRegisterInfo.td:
> def T0: RegisterWithSubRegs<"t0",[R0,R1]>;
> ...
> def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....]
>
> In mytargetISelLowering.cpp:
> I define i1, i8 , i16 and i32 are legal.
>
> 1. I still have problem. I save my function return double  value in  
> R0 and R1.
> It is expanded into two i32. But my GPR64 is defined to save i64.  
> llvm finds
> I have i64 GPR register. It will automatically decide not to expand  
> i64 to two i32.
>
> 2. I guess I need a special pseudo instruction to move between GPR32  
> and GPR64.
> How to move R0, R1 to T1( R2, R3 pair). and don't convert two i32 to  
> i64?
> Could I use MyTargetInstrInfo::copyRegToReg() to handle this logic  
> issue?

No. copyRegToReg only supports copying registers of the same (or  
compatible register classes).

>
>
> 3. Maybe I can study INSERT_SUBREG/EXTRACT_SUBREG at X86 porting file.

Yes.

>
>
> I will do some research more deeply. I think the best way is that  
> TableGen has register pair TypeProfile feature. :(

It's not a tablegen issue. It's easy to add the constraint to tablegen  
but the register allocator has to be able to allocate register pairs.  
That is definitely not a trivial task.

Evan

>
>
>
>
>
> But I find i64 data will not be ex
> --- 09年2月20日，周五, Evan Cheng <echeng at apple.com> 写道：
> 发件人: Evan Cheng <echeng at apple.com>
> 主题: Re: [LLVMdev] help: about how to use tblgen to constraint  
> operand.
> 收件人: hbrenkun at yahoo.cn, "LLVM Developers Mailing List" <llvmdev at cs.ui 
> uc.edu>
> 日期: 2009,220,周五,1:11上午
>
> 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
>
>
> 好玩贺卡等你发，邮箱贺卡全新上线！ 
> _______________________________________________
> 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/20090220/0be84356/attachment.html>