similar to: Type inference in TableGen DAG patterns

Displaying 20 results from an estimated 200 matches similar to: "Type inference in TableGen DAG patterns"

2016 Jan 13
2
Expanding a PseudoOp and accessing the DAG
I've got this PseudoOp defined: def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; let Constraints = "$dst = $addr" in { //, Uses= [GRP] in { def RelAddr : XSTGPseudo< (outs GPRC:$dst), (ins i64imm:$spoff,
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 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 //===----------------------------------------------------------------------===// def SDT_RELADDR :
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 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 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
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 13
2
Type inference in TableGen DAG patterns
Thanks, that worked. So that's basically a cast, then? I have another question about expanding that pseudo op, but I'll post it separately. Phil On Wed, Jan 13, 2016 at 10:26 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/13/2016 11:59 AM, Phil Tomson via llvm-dev wrote: > >> >> XSTGInstrInfo.td:908:73: error: expected variable
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; }
2018 Mar 28
1
Taking over an x86 opcode for my own instruction
tl;dr, I'd like to add my own instruction, but I'm running into problems due to my lack of x86 encoding/decoding understanding. Hello all. Currently, I'm working on adding my own x86 instruction. I have done this once before; the basic process I used was: 1. Find an unused opcode, e.g. 0xF1 in this table: http://ref.x86asm.net/coder32.html 2. Insert an instruction into
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)];
2016 Sep 28
2
Incompatible type assertion from llvm-tblgen
On Mon, Sep 26, 2016 at 2:24 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 9/26/2016 3:58 PM, Phil Tomson wrote: > >> 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 :
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
2016 Sep 26
2
Incompatible type assertion from llvm-tblgen
I'm getting this incompatible type assertion when I run tblgen on my .td files: llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::DefInit; Y = llvm::Init; typename llvm::cast_retty<X, Y*>::ret_type = llvm::DefInit*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible
2017 Dec 03
2
5.0.1-rc2 has been tagged
Hi, Tom, Considering the severity of this bug, I would like to go ahead to push the fix into release_50 branch. The fix has been tested in the trunk and by various people as well and I will also make sure all BPF tests passed before the push. Thanks! Yonghong On Fri, Dec 1, 2017 at 10:18 AM, Y Song <ys114321 at gmail.com> wrote: > Hi, Tom, > > I have a BPF backend bug which is
2015 Dec 02
4
lower 64 bits constant
Hi, All, I want to lower 64 Bits constant such as 'long' and 'double'. So I define them like this: def CONSTI64 : InstFOO<(outs GRWideRegs:$dst), (ins i64imm:$src), "const-long $dst, $src", [(set (i64 GRWideRegs:$dst), imm:$src)]>{ let isMoveImm = 1; } def CONSTF64 : InstFOO<(outs
2016 Oct 04
2
Incompatible type assertion from llvm-tblgen
On Wed, Sep 28, 2016 at 12:54 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 9/28/2016 2:44 PM, Phil Tomson wrote: > >> And map it to a load.idx instruction with the following semantics: >> load.idx r1,r2,r3,SIZE r1 <- mem[r2 + (r3 << sizeof(operand))] >> >> That somehow the pattern matching dag fragment would need to be
2017 Nov 30
9
5.0.1-rc2 has been tagged
Hi, I've tagged the 5.0.1-rc2 release, go ahead and start testing and report your results. -Tom
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 15
2
TableGen - Help to implement a form of gather/scatter operations for Mips MSA
Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from