similar to: [LLVMdev] xxRegisterInfo.td

Hi all, I just committed r183020 and r183061, that add Size/Offset information to SubRegIndex. If you maintain an out-of-tree target, there are a few things to change: - the SubRegIndex class has a new mandatory argument, representing the Size (in bits) covered by the index. If it's not meaningful (ex: same index for different kinds of registers), set it to -1 (though I believe this

You need to specify sub-register == super-register, idx relationship. See X86RegisterInfo.td: def x86_subreg_8bit : PatLeaf<(i32 1)>; def x86_subreg_16bit : PatLeaf<(i32 2)>; def x86_subreg_32bit : PatLeaf<(i32 3)>; def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], [AL, CL,

On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote: > > On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote: > > > What’s the value produced by an INSERT_SUBREG node? Is it a chain? > > > No, insert_subreg returns a value: > > > v1 = insert_subreg v2, v3, idx > > > v1 and v2 will have the same type, e.g. i16, and v3 must have a >

Hi I'm returning to my MC6809 back-end from a health-related hiatus. The assembler is tantalisingly close, but I've got some parsing and matching problems. The register set; these overlap in annoying ways, for instance, two instructions TFR and EXG each have a single opcode, and the post-byte specifies which registers are to be involved, but the registers can be 8- or 16-bit, and 2 of

On Oct 15, 2008, at 5:29 AM, sanjiv gupta wrote: > On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: >> You need to specify sub-register == super-register, idx relationship. >> See X86RegisterInfo.td: >> >> def x86_subreg_8bit : PatLeaf<(i32 1)>; >> def x86_subreg_16bit : PatLeaf<(i32 2)>; >> def x86_subreg_32bit : PatLeaf<(i32

On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: > You need to specify sub-register == super-register, idx relationship. > See X86RegisterInfo.td: > > def x86_subreg_8bit : PatLeaf<(i32 1)>; > def x86_subreg_16bit : PatLeaf<(i32 2)>; > def x86_subreg_32bit : PatLeaf<(i32 3)>; > > def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, >

This is the wrong code: declare <16 x float> @foo(<16 x float>) define <16 x float> @test(<16 x float> %x, <16 x float> %y) nounwind { entry: %x1 = fadd <16 x float> %x, %y %call = call <16 x float> @foo(<16 x float> %x1) nounwind %y1 = fsub <16 x float> %call, %y ret <16 x float> %y1 } ./llc -mattr=+avx

On Wed, 2008-10-15 at 10:08 -0700, Evan Cheng wrote: > On Oct 15, 2008, at 5:29 AM, sanjiv gupta wrote: > > > On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote: > >> You need to specify sub-register == super-register, idx relationship. > >> See X86RegisterInfo.td: > >> > >> def x86_subreg_8bit : PatLeaf<(i32 1)>; > >> def

Yes. But it is not really being used by most (any?) targets because post-RA scheduling is disabled by default. Also, the existing model is very limited in what types of micro-architectures can be described. I've been extending it to enable scheduling of multi-issue targets, targets with overlapping FU usage, and targets that use and define registers in multiple pipeline stages. See

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 ,

On Oct 15, 2008, at 11:21 AM, sanjiv gupta wrote: >>> >> >> Ok. The AX / AH super-reg and sub-reg relationship is not defined. In >> general x86 is not making good use of the high 8-bit sub-registers. >> We >> are leaving some performance on the table. We'll probably fix it one >> day. However, this doesn't apply to your target, right? There

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

I try to define a register class def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] to simulate even/odd pair of GPR32 register. Actually, I just use GPR64 as a temporary register. My CPU just support i32 Integer type directly. I use FDR to save f64. def FDR : RegisterClass<"mytarget", [f64], 64,[FD0, FD1, ....] When I move f64 to even/odd pair register, I

Hello Jeff, you're the first one to reply to my question :) I got a bit confused with the fact you said that the subregister class is larger than the superregister class. As far as i understood or what i tried to do with my code is to define a register pair composed of two 8 bit registers the way i described in my previous message. So R1R0 in WDREGS is directly mapped into R0 and R1 of GPR8.

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

Hi Evan, The problem repeats with the i8 and i16 variants, as well. Cheers, George On 21/12/2011 04:07, Evan Cheng wrote: > Thanks. Fixed with r147032. > > Evan > > On Dec 16, 2011, at 1:50 AM, George Russell wrote: > >> Hi, >> >> I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and >> ATOMIC_LOAD_UMAX_I* >> pseudo-instructions .

Hi, I don't know if anyone else has responded to your question, but I am currently in development of a register allocator. Thank you for bringing up the fact that sub-register classes may be larger than their super-register. If this remains the case, I for one will write a transform for my allocator which will make the 16 bit register the super-register with the 8bit as the sub. At least for

Actually after some digging I managed to answer these questions for myself. I am guessing that this information is used by the Schedule* classes in CodeGen. --- On Mon, 8/17/09, Carter Cheng <carter_cheng at yahoo.com> wrote: > From: Carter Cheng <carter_cheng at yahoo.com> > Subject: [LLVMdev] ARMSchedule.td MipsSchedule.td etc. > To: llvmdev at cs.uiuc.edu > Date:

I apologize if this has been asked before but which classes utilize the information in these files? I am asking since I am trying to extend the MIPS backend to 64bit among other things. Thanks in advance, Carter.

What files are created by the TableGen so that I can clean them out and start fresh? On Tue, Sep 11, 2012 at 3:11 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > ulimit -s = 8192 > set "ulimit -c unlimited" > > > > On Tue, Sep 11, 2012 at 3:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> John, >> >> Thanks for responding. No,