llvm dev - Sep 2016 - 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>

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

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>