search for: dregs

I am trying to make some modifications to our code generator that will produce better code, but require adding new patterns. What I am trying to do is take a register/register pattern and change it to a register/immediate. So for example, I have this pattern: class ILFormat<ILOpCode op, dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { let Namespace =

I'm not at the machine that has the changes, but it was failing at index 0. Micah From: Owen Anderson [mailto:resistor at mac.com] Sent: Thursday, April 19, 2012 3:35 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Tablegen to match a literal in an instruction Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output

Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output from llc -debug, and matching it up with the state machine in your DAGISel.inc to see at what step the auto-generated matcher is failing to match your and-with-immediate? -Owen On Apr 19, 2012, at 3:07 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > I am trying to make

Buenas tardes a todo el mundo, El motivo de que me dirija al foro es que no sé cómo añadir unas determinadas filas en un data table de una forma eficaz y según el identificador de sujeto. Además, quisiera hacerlo sin tener que recurrir a ningún paquete de R adicional del tipo plyr, dplyr, etc. (no sé si esto es posible). EJEMPLO: require(data.table) DT <- data.table( id =

Right, it's failing when it tries to materialize a move of a constant into a register. But it's only trying to do that because it previously failed to fold the constant into the AND. What you need to do is step through the path it takes when matching the AND node, and try to figure out why it ends up selecting the register-register version rather than the register-immediate version.

...r error after introducing the earlyclobber constraint to some instructions where the src and dest regs can't be the same. The offending instruction pattern is this one: let canFoldAsLoad = 1, isReMaterializable = 1, Constraints = "@earlyclobber $dst" in def LDDWRdPtrQ : Inst<(outs DREGS:$dst), (ins memri:$src), "lddw\t$dst, $src", [(set DREGS:$dst, (load addr:$src))]>; This is just a load with displacement instruction of the form "load reg, [reg_addr+<offs>]", where reg_addr and d...

...the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in the register classes for the load and store with displacement instructions: - load DREGS:$dst, PTR:$p - store DREGS:$src, PTR:$p where DREGS is a regclass composed of 16 registers and PTR is a regclass composed of 2 registers, but the key point here is that PTR is a subset of DREGS, so cross class copies are perfectly allowed. One of the 2 registers in the PTR regclass is reserved for...

Hello Jim thanks for the reply, For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: def : Pat<(add DLDREGS:$src1, imm:$src2), (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; Now, the typical pattern concerning additions with global addresses looks like this: (taken from x86) def : Pat<(add GR32:$src1, (X86Wrapper tglobaladdr :$src2)), (ADD32ri GR32:$src1, tglob...

On Apr 26, 2011, at 1:27 PM, Borja Ferrer wrote: > Hello Jim thanks for the reply, > > For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: > def : Pat<(add DLDREGS:$src1, imm:$src2), > (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; > Cool. That's exactly the sort of thing I was referring to. > Now, the typical pattern concerning additions with global addresses looks like this: (taken from x86) > def : Pat<(add...

...the earlyclobber constraint to some instructions where the src and dest regs can't be the same. The offending instruction pattern is this one: > > let canFoldAsLoad = 1, > isReMaterializable = 1, > Constraints = "@earlyclobber $dst" in > def LDDWRdPtrQ : Inst<(outs DREGS:$dst), > (ins memri:$src), > "lddw\t$dst, $src", > [(set DREGS:$dst, (load addr:$src))]>; > > This is just a load with displacement instruction of the form "load reg, [reg_addr+<offs>]&qu...

...Borja Ferrer wrote: > > > Hello Jim thanks for the reply, > > > > For normal additions with immediates I've done the same as ARM does, > basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in > the .td file like this: > > def : Pat<(add DLDREGS:$src1, imm:$src2), > > (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; > > > > Cool. That's exactly the sort of thing I was referring to. > > > > Now, the typical pattern concerning additions with global addresses looks > like this: (tak...

...ptimization or i missed something out here. This is for an out of tree backend im writing. I managed to reduce it to the following C function: void foo(int *a) // int here is 16bits { *a &= 0xFF; } This is the code before regalloc: Live Ins: %R25R24 %vreg0<def> = COPY %R25R24; DREGS:%vreg0 %vreg2<def> = COPY %vreg0; PTRREGS:%vreg2 DREGS:%vreg0 %vreg1<def> = LDWRd %vreg2; mem:LD2[%a](align=1)(tbaa=!"int") DLDREGS:%vreg1 PTRREGS:%vreg2 %vreg3<def> = ANDIWRdK %vreg1, 255; DLDREGS:%vreg3,%vreg1 %vreg5<def> = COPY %vreg0; PTRREGS:%v...

...to some instructions where the src and dest regs can't be the > same. The offending instruction pattern is this one: > > > > let canFoldAsLoad = 1, > > isReMaterializable = 1, > > Constraints = "@earlyclobber $dst" in > > def LDDWRdPtrQ : Inst<(outs DREGS:$dst), > > (ins memri:$src), > > "lddw\t$dst, $src", > > [(set DREGS:$dst, (load addr:$src))]>; > > > > This is just a load with displacement instruction of the form "load reg, &g...

...t; int c; > }; > void loop(struct ss *x, struct ss **y, int z) > { > int i; > for (i=0; i<z; ++i) > { > x->c += y[i]->b; > } > } > > The problem relies in the register classes for the load and store with displacement instructions: > - load DREGS:$dst, PTR:$p > - store DREGS:$src, PTR:$p > where DREGS is a regclass composed of 16 registers and PTR is a regclass composed of 2 registers, but the key point here is that PTR is a subset of DREGS, so cross class copies are perfectly allowed. > One of the 2 registers in the PTR regclass i...

https://bugzilla.netfilter.org/show_bug.cgi?id=979 --- Comment #3 from Alvaro <alvaroneay at gmail.com> --- (In reply to porjo38 from comment #0) > The output of nft_rule_snprintf_json() includes a JSON array called 'expr'. > I would like to suggest that each type be split into its own object where > the 'type' value becomes the key name. So for example, rather than

...re the src and dest regs can't be the >> same. The offending instruction pattern is this one: >> > >> > let canFoldAsLoad = 1, >> > isReMaterializable = 1, >> > Constraints = "@earlyclobber $dst" in >> > def LDDWRdPtrQ : Inst<(outs DREGS:$dst), >> > (ins memri:$src), >> > "lddw\t$dst, $src", >> > [(set DREGS:$dst, (load addr:$src))]>; >> > >> > This is just a load with displacement instruction of the for...

...be expaneded to ld r1, P+ ld r2, P where "ld _, P+" is an instruction that loads a single byte from P, and post-increments P by one. How can I represent this behaviour in LLVM? Currently, I have let Constraints = "@earlyclobber $reg" in def LDWRdPtr : Pseudo<(outs DREGS:$reg), (ins PTRREGS:$ptrreg), "ldw\t$reg, $ptrreg", [(set i16:$reg, (load i16:$ptrreg))]>, Requires<[HasSRAM]>; The problem, of course, is that with this definition I end up with code w...

We are syncing to 2.9 and we are hitting an with our backend in VerifySDNode in SelectionDAG.cpp. The first assert here is failing assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); Now, this is new to 2.9 and I am trying to understand what is invalid about what I am generating. What I generate has worked fine from LLVM version 2.4 until now without causing any issues.

...re you primarily trying to avoid Expand being implemented as a lib call with a larger type? No - I’m stuck in this situation: - 8-bit addition is legal - 16-bit addition is illegal, should expand into an add and an add with carry - A few operations support 16-bit operands - the 16-bit DREGS register class The legalizer sees that 16-bit addition should expand. It sees that there is a 16-bit register class, and it sees that 16-bit values are legal. As 16-bit is legal, it does not try and expand into a smaller type (8-bit). This causes instruction selection to fail. I can see why y...

Hello Jakob, thanks for the reply. The three regclasses involved here are all subsets from each other and aren't disjoint. These are the basic descriptions of the regclasses involved to show what i mean: DREGS: R31R30, R29R28 down to R1R0 (16 regs) DLDREGS: R31R30, R29R28 down to R17R16 (8 regs) PTRREGS: R31R30, R29R28, R27R26 (3 regs) All classes intersect each other giving as a result the smaller class: DREGSxDLDREGS=DLDREGS / DLDREGSxPTRREGS=PTRREGS, etc. That's why i think t...