Phil Tomson via llvm-dev
2016-Sep-26 20:58 UTC
[llvm-dev] 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 Mon, Sep 26, 2016 at 1:42 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 9/26/2016 3:36 PM, Phil Tomson via llvm-dev wrote:
>
>> def ADDR_SHLI : Addr< 2, "SelectAddrShlImm",
>> (ops GPRC:$base, ( shl GPRC:$offsetreg, (i64 3)))
>;
>>
>
> You have a dag in the list of operands. That won't work.
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160926/6b623266/attachment.html>
Krzysztof Parzyszek via llvm-dev
2016-Sep-26 21:24 UTC
[llvm-dev] Incompatible type assertion from llvm-tblgen
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 address?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 it. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Phil Tomson via llvm-dev
2016-Sep-28 19:44 UTC
[llvm-dev] 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 : Addr< 2, "SelectAddrRegImm", >> (ops GPRC:$base, i64imm:$offsetimm) >; >> >> Do I need to create some other intermediate node type for a shifted >> address? >> > > 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 > it. > > >Followup question: 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, 0x30d28b0<LD4[%arrayidx16(addrspace=4)](align=8)(tbaa=<0x3082188>)> [ORD=4] 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? Phil> -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160928/76993d6e/attachment.html>