[llvm-dev] Incompatible type assertion from llvm-tblgen
Phil Tomson via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 28 12:44:31 PDT 2016
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 : Addr< 2, "SelectAddrRegImm",
>> (ops GPRC:$base, i64imm:$offsetimm) >;
>> Do I need to create some other intermediate node type for a shifted
> Technically yes, but the list of allowed types is limited. "RegisterClass"
> (e.g GPRC) is allowed, as is "Operand" (e.g. i64imm).
> You can create a subclass of "Operand" and provide your EncoderMethod for
I was thinking that in order to match this DAG:
0x30d29c0: i64 = Constant<3>
0x30d2e00: i64 = shl 0x30d2be0, 0x30d29c0 [ORD=3]
0x30d2f10: i64 = add 0x30d2cf0, 0x30d2e00 [ORD=3]
0x30d28b0: <multiple use>
0x30d3570: i32,ch = load 0x30a3ec0, 0x30d2f10,
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 something
like I had in ADDR_SHLI definition:
def ADDR_SHLI : Addr< 2, "SelectAddrShlImm",
(ops GPRC:$base, ( shl GPRC:$offsetreg, (i64 3))) >;
Now If I have to create a subclass of Operand and define it's EncoderMethod
in C++, does that mean the pattern matching (matching the shift left and
add) now happens on the C++ side as well?
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev