similar to: [LLVMdev] Pat operands matching example in ppc

On 7 April 2013 14:54, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Hi Anitha, > > memri is just describing that the address contains two components, an > immediate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat

Hi Anitha, memri is just describing that the address contains two components, an immediate and a register, and how to handle them in the instruction printer. The STWU expects a memri operand, and that is what is passed from the Pat. Hope that helps, Sam On 07/04/2013 10:19, Anitha B Gollamudi wrote: > Hi, > > > How do "Pat" operands get matched? I am trying to follow

Hi all, I've been poking at AsmParser support for powerpc64 (ppc64-elf-linux-abi) and have run into some behavior I don't understand with the ptr_rc references coming out of the PPC*.td files when generating the asm-matcher files. For instance : $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher

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

On Fri, 2012-09-14 at 13:10 -0500, Will Schmidt wrote: > Hi all, > > I've been poking at AsmParser support for powerpc64 > (ppc64-elf-linux-abi) and have run into some behavior I don't understand > with the ptr_rc references coming out of the PPC*.td files when > generating the asm-matcher files. > > For instance : > $ ./build/bin/llvm-tblgen

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

Hi Hal, On Tuesday 01 October 2013 06:22 PM, Hal Finkel wrote: > ----- Original Message ----- >> 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

On Wed, 2012-09-19 at 18:41 -0500, Will Schmidt wrote: > On Fri, 2012-09-14 at 13:10 -0500, Will Schmidt wrote: > > Hi all, > > > > I've been poking at AsmParser support for powerpc64 > > (ppc64-elf-linux-abi) and have run into some behavior I don't understand > > with the ptr_rc references coming out of the PPC*.td files when > > generating the

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote: > Hello Dale, > > this is an updated version of the tail call optimization patch for > powerpc. could you have a look at it? > > i added code to support ppc64 (untested, will try to get access to > ppc64 on a friend's machine). > incorporated evan's formatting suggestions. ;) > > will run another round

On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> wrote: > More nitpicks: > ... > No need for else here. :-) Done > SPDiff = (int)CallerMinReservedArea - (int)ParamSize; > > Just change last statement to > int SPDiff = (int)... Done > > +bool > +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, > +

Hi, I'd like to define a pseudo-instruction whose expansion will, as a side-effect, overwrite an input register's value: the pseudo-instruction ldw r1:r2, P to load 2 bytes from memory address P is to 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

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

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

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

I'm attempting to implement codegen support for the AVR ST/LD <http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_ST.html> family of instructions. The binary encoding is not particularly consistent -- take a look at this table of variants of LD, along with their machine code representation: # load 8 bits from pointer register X into general purpose Rd ld Rd, X `1001 000d dddd

Hello, I'm new to LLVM and I'm using it to translate from LLVM to another language rather than emitting actual machine code. The target language 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:

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint

Hi, I'm trying to add the xadd instruction to the X86 back end. xadd r/m32, r32 exchanges r/m32 and r32, and loads the sum into r/m32. I'm interested in the case where the destination operand is a memory location. I've added the following entry to X86InstrInfo.td: def XADD32mr : I<0x87, MRMDestMem, (ops i32mem:$src1, R32:$src2), "xadd{l}

Are there any other patterns in your TD file? If so, then one of the ones before this pattern will match everything, and this pattern will never be matched. -bw On Jul 3, 2009, at 8:27 PM, Javier Martinez wrote: > Hello, > > I'm new to LLVM and I'm using it to translate from LLVM to another > language rather than emitting actual machine code. The target language > has