[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
>> 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?


> -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>

More information about the llvm-dev mailing list