search for: ptrreg

..."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 which assumes it is equivalent to save P befo...

...**** entry: 16L %vreg0<def> = COPY %R25R24<kill>; DREGS:%vreg0 Considering merging %vreg0 with physreg %R25R24 RHS = %vreg0 = [16d,96d:0) 0 at 16d LHS = %R25R24,inf = [0L,16d:0) 0 at 0L-phidef updated: 96L %vreg8<def> = COPY %R25R24<kill>; PTRREGS:%vreg8 updated: 32L %vreg5<def> = COPY %R25R24; PTRREGS:%vreg5 Joined. Result = %R25R24,inf = [0L,96d:0) 0 at 0L-phidef 32L %vreg5<def> = COPY %R25R24; PTRREGS:%vreg5 Not coalescable. 64L %vreg6<def> = COPY %vreg4<kill>; DLDREGS:%vreg6,%vreg4 C...

..., 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 the coalescer should work since the regclasses overlap completely. -------------- next part ------------...

...is what is passed from the Pat. > My confusion is how operands of STWU from "Pat pre_store" get matched with those of memri. It is defined with operand types as: let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); while Pat is defined as: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; So now how iPTR:$ptrreg and iaddroff:$ptroff get matched with ptr_rc_nor0:$reg and dispRI:$imm respectively? I mean the types are not exactly matching. Probably something is amiss in my understanding. -Anitha > >...

Thanks. I saw the header comments but it wasn’t clear to me what the difference between those concepts is? My slightly vague understanding is IsDef means that the register specified by this operand is set by the machine instruction. So I understand that to mean the MO will override that register? Also things like early clobber, perhaps there is another document that clarifies some of these

...ly. 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 the coalescer should work since the regclasses overlap completely. Cross class coalescing als...

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of stwu should get matched with the given pre_store. But I am confused as to how "ptroff" and "ptrreg" get matched with "memri" used in STWU?...

...vreg0<def> = COPY %R25R24<kill>; DREGS:%vreg0 > Considering merging %vreg0 with physreg %R25R24 > RHS = %vreg0 = [16d,96d:0) 0 at 16d > LHS = %R25R24,inf = [0L,16d:0) 0 at 0L-phidef > updated: 96L %vreg8<def> = COPY %R25R24<kill>; PTRREGS:%vreg8 > updated: 32L %vreg5<def> = COPY %R25R24; PTRREGS:%vreg5 > Joined. Result = %R25R24,inf = [0L,96d:0) 0 at 0L-phidef > 32L %vreg5<def> = COPY %R25R24; PTRREGS:%vreg5 > Not coalescable. > 64L %vreg6<def> = COPY %vreg4<kill>; DL...

...uot; operands get matched? I am trying to follow the example > given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process > > In the latest trunk of ppcintrinfo.td <http://ppcintrinfo.td> > following pattern is defined: > > def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), > (STWU $rS, iaddroff:$ptroff, $ptrreg)>; > > I understand that input operand list i.e. ins of stwu should get > matched with the given pre_store. But I am confused as to how > "ptroff" and "ptrreg" get matched with "me...

On Sun, 28 May 2017, David Chisnall wrote: >> 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 which as...

I can't get it to work with pattern matching. My operand is defined like so: def LDSTPtrReg : Operand<i16> { let MIOperandInfo = (ops PTRREGS); let EncoderMethod = "encodeLDSTPtrReg"; } I am able to use it in the place of PTRREGS in the definition of the LD instruction, but if I use it in an instruction matching pattern, compilation fails with the error "Unkn...

Hi Ryan, > On Mar 14, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I looked at this again and it appears that while spillAroundUses sets the register as 'dead', there is no checking to see if it's dead in subsequent iterations of the bundle loop. > > Is this intentional? > > On Mon, Mar 7, 2016 at 3:28 PM, Ryan

...it One way to solve this solution would be to to describe them in InstrInfo.td as seperate instructions. Note that R27R26 is a pointer register defined in AVRRegisterInfo.td, and 'X' is an alias for this. let Uses = [R27R26], canFoldAsLoad = 1, isReMaterializable = 1 in def LDRdX : FSTLDPtrReg<0b0, (outs GPR8:$reg), (ins), "ld\t$reg, X", [(set GPR8:$reg, (load R27R26))]>; def LDRdY : FSTLDPtrReg<0b0, // ... When I do this, however, I get errors that the pointer r...

...s 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:%vreg5 DREGS:%vreg0 STWRr %vreg5, %vreg3<kill&...

...guage has instructions that operate on pointers which aren't naturally exposed in LLVM. Here's what I've done to add pointer support for an instruction called PADD that takes a pointers and an offset and returns the new pointer value: def DefReg : Register<"r">; def PtrReg : Register<"ptr">; def I32RC : RegisterClass<"BE", [i32], 32, [DefReg]>; def P32RC : RegisterClass<"BE", [i32], 32, [PtrReg]>; def BEInst<bits<8> op, dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { /* assign arg...

...e output operand. For example, the PowerPC backend has a pre-increment store encoded like this: def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), "stdux $rS, $dst", LdStSTDU, []>, RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; } def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), (STDUX $rS, $ptrreg, $ptroff)>; Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are correct, however, that...

...pointers which aren't naturally > exposed > in LLVM. Here's what I've done to add pointer support for an > instruction > called PADD that takes a pointers and an offset and returns the new > pointer value: > > def DefReg : Register<"r">; > def PtrReg : Register<"ptr">; > def I32RC : RegisterClass<"BE", [i32], 32, [DefReg]>; > def P32RC : RegisterClass<"BE", [i32], 32, [PtrReg]>; > def BEInst<bits<8> op, dag outs, dag ins, string asmstr, list<dag> > pattern> : Instruct...

...example, the PowerPC backend has a pre-increment store encoded like this: > > def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), > "stdux $rS, $dst", LdStSTDU, []>, > RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; > } > > def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), > (STDUX $rS, $ptrreg, $ptroff)>; > > Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. Y...

Hi Hal, Our Architecture has indirect move instruction which increments the pointer implicitly and the target only has i8 type values. So the load of i16 will be converted to two i8 target loads wherein after the first load instruction, the pointer to the first i8 address will automatically increment to point to the next i8 value. So the post increment nature is in the Target. A normal

...emitted for the intrinsic function: call int (<integer type>*, <integer type>)* %llvm.atomic_fetch_add_store(<integer type>* <pointer>, <integer type> <value>) I currently have the following code (PtrReg contains the pointer argument, ValReg the value arg, and TmpReg an unused register.): addDirectMem(BuildMI(BB, X86::XADD32mr, 4, TmpReg).addReg(TwoReg), ValReg); This fails the assertion isMem. Any help with this would be appreciated. Thanks, Brent