[llvm-dev] Incompatible type assertion from llvm-tblgen

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 28 12:54:56 PDT 2016

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

Actually the EncoderMethod is probably not needed for this case. I 
thought you had a scaled immediate that needs to be shifted during encoding.

Regarding pattern matching in the C++ code---yes, that's what 
ComplexPattern implies. The function whose name you provide will be used 
to match the DAG and generate the output.

The instruction definition would have 3 inputs: register, register and 

def ADDR_SHLI: Addr<3, "SelectAddrShlImm",
     (ops GPRC:$base, GPRC:$offsetreg, i64imm:$shift)>;

The matching function would then need to match DAG and generate these 3 
values if the match succeeded.


Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

More information about the llvm-dev mailing list