similar to: Expanding a PseudoOp and accessing the DAG

On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote: > >> I've got this PseudoOp defined: >> >> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; >> def XSTGRELADDR :

Given the following definitions: def SDT_XSTGMVINI : SDTypeProfile<1, 1, [SDTCisInt<0>]>; def XSTGMVINI : SDNode<"XSTGISD::MVINI", SDT_XSTGMVINI>; def SDT_RELADDR : SDTypeProfile<1, 2, []>; def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; let Constraints = "$dst = $addr", Uses= [GRP] in

On Thu, Jan 7, 2016 at 1:35 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org > wrote: > On 1/7/2016 3:25 PM, Phil Tomson wrote: > >> >> That's better, but now I get: >> >> XSTGInstrInfo.td:902:3: error: In RelAddr: XSTGRELADDR node requires >> exactly 2 operands! >> >> Which makes some sense as XSTGRELADDR is defined as: >> def

On Thu, Jan 14, 2016 at 6:05 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 1/13/2016 4:47 PM, Phil Tomson wrote: > >> >> First off, I got this idea from the LLVM Cookbook chapter 8: Writing an >> LLVM Backend: Lowering to multiple instructions. (now I'm having my >> doubts as to whether this is the right approach) >> > >

I'm trying to figure out what this error message means: error: In RelAddr: Top-level forms in instruction pattern should have void types The definitions it's complaining about: //===----------------------------------------------------------------------===// // RELADDR //===----------------------------------------------------------------------===// def SDT_RELADDR :

On 1/7/2016 5:54 PM, Phil Tomson wrote: > I got it to compile by changing to: > def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, > SDTCisSameAs<0, 1>]>; > def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; > > let Uses= [GRP] in { > def RelAddr : XSTGPseudo< (outs GPRC:$dst), >

On Thu, Jan 7, 2016 at 12:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/7/2016 1:55 PM, Phil Tomson via llvm-dev wrote: > >> >> let Uses= [GRP] in { >> def RelAddr : XSTGPseudo< (outs), >> (ins GPRC:$spoff, GPRC:$dst), >>

On 1/15/2016 1:08 PM, Phil Tomson wrote: > > Ah, I see, the defm is a multi-class so I needed to change it to: > > def: Pat<(load (XSTGADDR_NORMAL tglobaladdr:$addr)), > (LOADI64_RI tglobaladdr:$addr, 0)>; > // Match load from a relocatable address to a load with GRP: > def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)), > (LOADI64_RI

On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode,

Hi Jiangning, On Apr 15, 2014, at 11:12 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Quentin, > > Thanks for your feedback! >> ​ARM64 generates pseudo instructions ARM64::MOVaddr and friends in ISEL stage, which intends to guarantee address serialization (page address + in-page address), and exposes adrp finally by pass ExpandPseudoInsts. The assumption of

Hello. I have problems specifying vector instructions with immediate values in TableGen. I wrote the following specification (I got inspired from the MSA vector instructions for the Mips back end): class MSA_I16_FMT<bits<9> opcode>: MSAInst { bits<16> s16; let Inst{31-23} = opcode; let Inst{26-11} = s16; }

Hi Alex, On 5 December 2016 at 18:00, Alex Susu <alex.e.susu at gmail.com> wrote: > We can compile it. Note that this is the only compilable code w.r.t. > using i64 or i64imm (in the 2 lines above: "dag InOperandList", "list<dag> > Pattern"). Yeah, you actually want to use "imm": list<dag> Pattern = [(int_repeat_x_times imm:$imm)];

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

Hello, I'm considering creating an LLVM backend for a 16 bit processor and modelling it around the (experimental) MSP430 back end. When reviewing MSP430InstrInfo.td I see def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; and can see in MSP430ISelLowering.cpp that ISD::GlobalAddress: ISD::BlockAddress: ISD::ExternalSymbol all get lowered to

Hi Jacob, thank you for your reply. Your suggestion works! But instead of using the Pat<>, I am using def MOVE_ADDR : MYInst<(outs Int32Regs:$dst), (ins i32mem:$a), "move $dst, $a;", [(set Int32Regs:$dst, (Wrapper tglobaladdr:$a))]>; I don't quite understand what the semantics of Pat in general. Could you please explain what

Hello, I am learning to write a new backend for LLVM and have a few simple questions. 1) What are the differences between 'constant' and 'targetconstant', 'globaladdress' and 'targetglobaladdress'? It is not clear from the document when and which should be used. 2) On the processor I am working on, there is a 'move reg, mem_addr' instruction. When I try

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

Thanks Jim, I've implemented the negation part successfully :) maybe the second part could be a possible feature request so others could use it aswell? 2011/4/27 Jim Grosbach <grosbach at apple.com> > > 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

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

But don't the defs for ADDR_RR and ADDR_RI also contain dags? def ADDR_RR : Addr< 2, "SelectAddrRegReg", (ops GPRC:$base, GPRC:$offsetreg) >; def ADDR_RI : Addr< 2, "SelectAddrRegImm", (ops GPRC:$base, i64imm:$offsetimm) >; Do I need to create some other intermediate node type for a shifted address? Phil On