similar to: Expanding a PseudoOp and accessing the DAG

Displaying 20 results from an estimated 400 matches similar to: "Expanding a PseudoOp and accessing the DAG"

2016 Jan 13
2
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 :
2016 Jan 13
2
Type inference in TableGen DAG patterns
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
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
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:
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
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) >> >
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
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
2016 Jan 08
2
TableGen error message: top-level forms in instruction pattern should have void types
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), >
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
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), >>
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
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)), >
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
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, >
2014 Apr 16
3
[LLVMdev] Proposal: AArch64/ARM64 merge from EuroLLVM
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
2016 Dec 03
2
Immediate operand for vector instructions
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; }
2016 Dec 06
0
Immediate operand for vector instructions
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)];
2011 Apr 26
2
[LLVMdev] Symbol folding with MC
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
2012 Jul 25
2
[LLVMdev] Purpose of MSP430Wrapper
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
2009 Apr 20
2
[LLVMdev] A few questions from a newbie
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
2009 Apr 20
2
[LLVMdev] A few questions from a newbie
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
2011 Apr 26
0
[LLVMdev] Symbol folding with MC
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))>;
2011 Apr 27
1
[LLVMdev] Symbol folding with MC
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
2016 Sep 26
2
Incompatible type assertion from llvm-tblgen
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
2012 Jul 25
2
[LLVMdev] Purpose of MSP430Wrapper
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 :