similar to: [LLVMdev] INSERT_SUBREG node.

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 >

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, >

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 sub- register type, e.g. i8. > Can I use to set a superreg of i16 type with two i8 values, and use > the supperreg as

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 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

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 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

On Thu, 2008-10-16 at 08:55 -0700, Evan Cheng wrote: > 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

On Oct 18, 2008, at 7:01 AM, sanjiv gupta wrote: > On Thu, 2008-10-16 at 08:55 -0700, Evan Cheng wrote: >> 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

On Sun, 2008-10-19 at 23:18 -0700, Evan Cheng wrote: > > On Oct 18, 2008, at 7:01 AM, sanjiv gupta wrote: > > > On Thu, 2008-10-16 at 08:55 -0700, Evan Cheng wrote: > > > On Oct 15, 2008, at 11:21 AM, sanjiv gupta wrote: > > > > > > > > > > > > > > > > > > > Ok. The AX / AH super-reg and sub-reg relationship is

On Oct 20, 2008, at 7:10 AM, sanjiv gupta wrote: >>> >>> PR2916 filed. >>> Though I did not quite understand why this could be a tablegen bug? >> >> >> Based on your comments. :-) It should be possible to specify two FSR0 >> sub-registers (FSR0L, FSR0H of the same register class FSR8) with the >> workaround you described: >> >>

On Mon, 2008-10-20 at 08:07 -0700, Evan Cheng wrote: > On Oct 20, 2008, at 7:10 AM, sanjiv gupta wrote: > > >>> > >>> PR2916 filed. > >>> Though I did not quite understand why this could be a tablegen bug? > >> > >> > >> Based on your comments. :-) It should be possible to specify two FSR0 > >> sub-registers (FSR0L,

Hi all, We are working on a backend for a machine that has 4-wide vector register & ops, *but* not vector loads. All the vector register elements are directly accesible, so VI1 reg (Vector Integer 1) has I4, I5, I6 and I7 as its (integer) subregisters. Subregisters of same reg *never* overlap. Therefore, vector loads are lowered to scalar loads followed by a chain of INSERT_VECTOR_ELTs. Then

The new SUBREG target-independent instructions aren't getting mayLoad/mayStore flags set correctly. For example, in the generated X86GenInstrInfo.inc file, there is only one entry for INSERT_SUBREG: { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the

Hello Tom, > I took a look at lib/CodeGen/SelectionDAG/LegalizeDAG.cpp and it > doesn't look like there is an Expand operation implemented for > ISD::Constant. I think you'll either need implement Expand for > ISD::Constant or Custom lower it in your backend. thank you for that information. This exactly is what I feared. Well I did some more mostly unguided hacking and these

On Thu, Jul 12, 2012 at 01:22:39PM +0200, Fabian Scheler wrote: > Hi Micah, > > > We have a very similar setup with the AMDIL backend(some operations support 64bit some don't). > > > > What we do is we enable MVT::i64, set legal to all operands that are legal and then set everything else to expand. > > thanks for your hint. Unfortunately, I didn't find any

Hi Micah, > We have a very similar setup with the AMDIL backend(some operations support 64bit some don't). > > What we do is we enable MVT::i64, set legal to all operands that are legal and then set everything else to expand. thanks for your hint. Unfortunately, I didn't find any time to work on my problem in the meantime as I was busy preparing lectures. However, the summer

Hi, I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : // BEFORE LOOP ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2

If I write %reg16506<def> = INSERT_SUBREG %reg16506, %reg16445, hi16; #1 %reg16506<def> = INSERT_SUBREG %reg16506, %reg16468, lo16; #2 store %reg16506 #3 it will not coalesce, as LiveVariables: on #2: %16506 gets #2 as a kill #3: %16506 gets #3 as an additional kill LiveIntervalAnalysis:

Hi, Recently code using IMPLICIT_DEF and INSERT_SUBREG started to break: %vreg9<def> = IMPLICIT_DEF %vreg10<def> = INSERT_SUBREG %vreg9<kill>, %vreg1<kill>, hi %vreg12<def> = sub %vreg10<kill>, %vreg11<kill> => %vreg10<def> = IMPLICIT_DEF %vreg10:hi<def> = COPY %vreg1<kill>