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