search for: selectaddr

...e second load. I need the result to be: m0 = 4 r1 = *(i0 += m0) (offset is stored in a register(m0), and modifies the original pointer) rather than r1 = *(i0 + 4) (immediate) (The specific registers numbers don't matter). I'm not sure how to achieve that. Currently addr gets matched in SelectAddr in XYZISelDAGToDAG.cpp. It will match the add node and "combine" (I'm not sure this is the correct terminology) it into my LDR node. The result of this can be seen sched.png So instead of that TargetConst<4> I need a something that copies 4 into an M register, and then LDR uses...

...ible addressing similar to what the x86 can do, only that the adressing base has to reside in an address register: move.size[b/w/l] <Displacement>(Ax, Dx * Scale[1/2/4/8]), <Dest> -- Dest = *(Ax + Displacement + Dx * Scale) This is very powerful and suits a variant of the X86 backend SelectAddr() pretty well, so I've adapter pieces of that code for my own little backend. The issue I'm pondering is how to ensure that addresses end up in address registers just before the load. We discussed different alternatives on the list a while back such as pseudo registers and fixup passes; bu...

I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; def MEM : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st : SDNode<"AMDILISD::GLOBAL_STORE", SDTStore, [SDNPHasChain, SDNPMayLoad, SDNPMemOperand]>; def global_store :...

..."pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23, 2014 at 12:23 PM, Steve Montgomery < stephen.montgomery3 at btinternet.com> wrote: > You might need to modify selectAddr so it doesn't fold the add node but > instead returns two operands: one for the pointer and one for the offset. > You can control the register classes for the two components of the address > using MIOperandInfo so your base pointer can be IClass and the offset > MClass. See SparcIns...

On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I’m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; > def MEM : Operand<i32> { > let PrintMethod = "printMemOperand"; > let MIOperandInfo = (ops GPR, GPR); > } > def global_st : SDNode<"AMDILISD::GLOBAL_STORE", SDTStore, > [SDNPHasChain, SDNPMayLoad, SDNPMemOperand]>;...

...iliar with compiler > terminology, so I don't know if there is a proper term for such a > load. > > > > > > > On Thu, Oct 23, 2014 at 12:23 PM, Steve Montgomery < > stephen.montgomery3 at btinternet.com > wrote: > > > You might need to modify selectAddr so it doesn't fold the add node > but instead returns two operands: one for the pointer and one for > the offset. You can control the register classes for the two > components of the address using MIOperandInfo so your base pointer > can be IClass and the offset MClass. See SparcIns...

2008/2/15, Andreas Fredriksson <deplinenoise at gmail.com>: > > I tried mocking this up using the following. (Base is what's returned as > the Ax in the move expression above when the DAG is constructed due to > SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32); > Replying to myself here. This worked a bit better :) const unsigned addressReg = RegMap->createVirtualRegister(&M68K::AR32RegCl...

...2. The x86 backend currently does not support dereferencing 32-bit addresses in 64-bit mode. Specifically, addresses are defined as an iPTR type in X86InstrInfo.td which I assume is expanded to 4 or 8 bytes depending on if 32/64 bit mode is active: def addr : ComplexPattern<iPTR, 5, "selectAddr", [], [SDNPWantParent]>; The derefencing mov instruction looks like this: def MOV32rm : I<0x8B, MRMSrcMem, (outs GR32:$dst), (ins i32mem:$src), "mov{l}\t{$src, $dst|$dst, $src}", [(set GR32:$dst, (loadi32 addr:$src))], IIC_MOV_MEM>, OpSize32; So it expect...

Hi Bruce, Thanks for you reply. I check the *.td files under the lib/Target/X86 folder, but have not got interesting findings. It requires some knowledge of LLVM backend to fully understand the *.td files. I will get some background and keep searching. Of course I appreciate if anyone with such experience can point the concrete locations. Regards, Hu Hong On 17 October 2016 at 22:20, Bruce

...urrently does not support dereferencing 32-bit > addresses in 64-bit mode. Specifically, addresses are defined as an > iPTR type in X86InstrInfo.td which I assume is expanded to 4 or 8 > bytes depending on if 32/64 bit mode is active: > def addr : ComplexPattern<iPTR, 5, "selectAddr", [], > [SDNPWantParent]>; > The derefencing mov instruction looks like this: > def MOV32rm : I<0x8B, MRMSrcMem, (outs GR32:$dst), (ins i32mem:$src), > "mov{l}\t{$src, $dst|$dst, $src}", > [(set GR32:$dst, (loadi32 addr:$src))], IIC_MOV_MEM&gt...

...: Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPRegs, GPRegs); let EncoderMethod = "getMemEncoding"; } def addr : ComplexPattern<i32, 2, "SelectAddr", [frameindex], [SDNPWantParent]>; def LDRAM : FG1<0b000001, (outs GPRegs:$dst), (ins mem:$src), "ldram $dst,$src", [(set GPRegs:$dst, (load addr:$src))]>; def STRAM : FG1<0b000010, (outs), (ins GPRegs:$src, mem:$dst), "stram $dst,$src", [(store GPRegs:$src, ad...

Hi All I'm having nightmares with FrameIndexes during my backend development :( I have ComplexPatterns defined for my two addressing modes (RR and RI). Most of the time, FrameIndex operands appear to be on load/store nodes, in which case everything works fine as my custom addressing modes matchers work fine. Unfortunately, I now have an add node which has a FrameIndex operand (this results

...)), (LHu addr:$src)>; to: def : Pat<(i32 (extloadi16_a addr:$src)), (OR (LBu addr:$src), (SLL (LBu addr:($src+1)), 8))>; However, it failed to compiled. It seems that ($src+1) is a wrong representation in TableGen. I find the definition of adds: def addr : ComplexPattern<iPTR, 2, "SelectAddr", [frameindex], [SDNPWantParent]>; How to calculate a new address in TableGen? Thanks, Yang

Hi Chris, > On Wed, 6 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > > The ARM has some very powerful and complex addressing modes. For > > example, the data processing instructions (and, orr, add, ..) have > > an addressing mode that has 11 options (imm, reg, and 9 reg + some > > shift). > > I'm not sure exactly what the constraints you have are For those

i'm getting a Could not infer all types in pattern! error in my backend. it is happening on the following instruction: VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). how do i make it use appropriate types? in other words if it is f32 then use v4v32 and if it is i32 then use v4f32. i'm not sure even where to start? any help is appreciated.

...arithmetic or logic instructions, therefore load the constant first into a register add r4, r4, sp // calc the memory address ldr r5, r4 // load indirect from memory address in r4 to register I looked into other backends, eg. AVR or CPU0. I found out that most likely the main topic is to adapt the SelectAddr function in LEGISelDAGToDAG.cpp so the offset it not used anymore. I do not know how to solve this. Does someone have a hint for me? I would very much appreciate it. Best regards Georg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piperm...

On Jul 13, 2009, at 10:02 AM, David Greene wrote: >>> - Tag instructons with source line information (customers really >>> want this). >> >> Right, that would be nice. This should be synthesizable from the >> DebugLoc on the instruction in the asm printer, no need to >> redundantly >> encode it into the comment field. > > Except the DebugLoc

...de into an add(frame address, offset) node - I am currently having a hard time extracting the offset in the FrameIndex node. I have also read (From “Using frameindex in a pattern” llvm-dev archive, referring to the Sparc target) that adding frameindex into the def addr : Complex Pattern<…,”SelectAddr”,…> would only translate it into a targetframeindex with an offset of 0. - In the AVR target, the ISD::FrameIndex has a custom select transforming it into an AVR:FRMIDX node and then later processed in the eliminateFrameIndex. Is this equivalent to the process I am trying to do? - Wh...

Hi! I'm making a strange observation in my backend, that ends in illegal code: Version 1: - I lower FrameIndex to TargetFrameIndex (nothing special) - I generate a special address-register ADD instruction in eliminateFrameIndex() to write FramePointer + offset into a new address-register - I use explicit load and store and address-registers in my target instruction patterns: eg (store

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > I was attempting to reduce the number of files affected, but if you > > want this change I'll go ahead and do it. > > Makes sense, thanks. Please do it as a separate patch from the other > changes though since it will be large and mechanical. Ok, no problem. > > - Tag instructons with source line information