[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