search for: g_mul

...pened as the de-duplication and unordered nature of the DAG produced the same result either way. For MIR, each builder needs to insert into a linear list so the evaluation order of those insertions matters. For example: getAdd(getSub(a, b), getMul(c, d)) could produce either: %0 = G_SUB %a, %b %1 = G_MUL %c, %d %2 = G_ADD %0, %1 or: %0 = G_MUL %c, %d %1 = G_SUB %a, %b %2 = G_ADD %1, %0 depending on the (indeterminate) evaluation order of the arguments to getAdd(). The G_ADD is always last because getSub() and getMul() must execute before getAdd() but AFAIK there's nothing that controls the rela...

...tion $MI2)), (DBG_VALUE $D, debug_local:$MI3, debug_expr:$MI3, (debug_location $MI3))))>; // $VAL is needed to indicate it's an immediate and provide the predicate def : GICombineRule<(defs reg:$D, reg:$A, imm_2:$VAL), (match (G_MUL $D, $A, $VAL)), (apply (MYTGT_DOUBLE $D, $A))>; // $B/$C are needed to indicate they're immediates and provide $C's predicate def : GICombineRule< (defs reg:$D, reg:$A, imm:$B, imm_2:$C), (match (G_ADD $t1, $A, $B), (G_MUL $D, $...

...2)), >> (DBG_VALUE $D, debug_local:$MI3, debug_expr:$MI3, (debug_location $MI3))))>; >> // $VAL is needed to indicate it's an immediate and provide the predicate >> def : GICombineRule<(defs reg:$D, reg:$A, imm_2:$VAL), >> (match (G_MUL $D, $A, $VAL)), >> (apply (MYTGT_DOUBLE $D, $A))>; >> // $B/$C are needed to indicate they're immediates and provide $C's predicate >> def : GICombineRule< >> (defs reg:$D, reg:$A, imm:$B, imm_2:$C), >> (match (G_ADD $t1, $A, $B), >> (G_MUL $D,...

Hi, I’m finding the API for MachineIRBuilder to be pretty annoying to use compared to SelectionDAG. I think it’s making the majority of code more verbose and unwieldly for anything less than trivial. I think changing it to behave more like the DAG.get* functions would make it easier to use, and decrease the mental overhead when porting code from SelectionDAG. The main issue is needing to create

...ular question arose because we are seeing the following LLVM-IR, which we cannot legalize with our current legalization rules:     %6 = zext i32 %5 to i33     %7 = zext i32 %0 to i33     %8 = mul i33 %6, %7     %9 = lshr i33 %8, 1     %10 = trunc i33 %9 to i32   getActionDefinitionsBuilder(G_MUL)       .legalFor({s32})       .clampScalar(0, s32, s32);   getActionDefinitionsBuilder(G_LSHR)       .legalFor({{s32, s32}})       .clampScalar(1, s32, s32)       .clampScalar(0, s32, s32); We would be able to legalize the above code if we just add a widenScalarToNextPow2 before the clampS...

...MI3, (debug_location $MI3))))>; Matching immediates and G_CONSTANT/G_FCONSTANT There isn't much that's special about the changes in this section. Rewriting the examples into the DAG style gives: def : GICombineRule<(defs reg:$D, reg:$A, imm:$VAL), (match (G_MUL $D, $A, $VAL), (isTwo imm:$VAL)), (apply (MYTGT_DOUBLE $D, $A))>; Or equivalently: def imm_2 : GIPredicatedDefKind<(isTwo imm)>; def : GICombineRule<(defs reg:$D, reg:$A, imm_2:$VAL), (match (G_MUL $D...

...and how to legalize them. This was necessary to implement support for the new extending loads and truncating stores, but also results in more concise and elegant expressions of legality for each target. For example, you can now apple a single definition to apply to multiples opcodes (G_ADD, G_SUB, G_MUL etc). The IR translator has been modified to split aggregates rather than handling them as one single large scalar. This change fixed some bugs and was necessary in order handle big endian code correctly in future. The tablegen instruction selector also saw significant improvements in performance...

...necessary to implement support >> for the new extending loads and truncating stores, but also results in more >> concise and elegant expressions of legality for each target. For example, >> you can now apple a single definition to apply to multiples opcodes (G_ADD, >> G_SUB, G_MUL etc). >> >> The IR translator has been modified to split aggregates rather than handling >> them as one single large scalar. This change fixed some bugs and was >> necessary in order handle big endian code correctly in future. >> >> The tablegen instruction sel...

...necessary to implement support >> for the new extending loads and truncating stores, but also results in more >> concise and elegant expressions of legality for each target. For example, >> you can now apple a single definition to apply to multiples opcodes (G_ADD, >> G_SUB, G_MUL etc). >> >> The IR translator has been modified to split aggregates rather than handling >> them as one single large scalar. This change fixed some bugs and was >> necessary in order handle big endian code correctly in future. >> >> The tablegen instruction sel...

Hi all, recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be narrowed because the narrowing code relies on G_UNMERGE_VALUES and therefore requires the source type to be a multiple of the narrow type. Often times these instructions can be widened without any problem to a fitting type. This has us writing legalization rules like

> On Nov 10, 2018, at 03:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Thank you for the detailed reply! There's a lot to digest :) Let me try to address most of it. > > > [snip] >>> I also think you should have 'ins' and 'outs' separately; after all, a predicate may have to do a combined check on two matched registers / operands,

...g defined by G_CONSTANT or G_FCONSTANT. All three forms are handled by the 'imm' declaration. Here we declare rule that matches X * 2 using a custom predicate to check the immediate is 2: def : GICombineRule<(defs root:$D, reg:$A, imm:$VAL), (match [{MIR %D = G_MUL %A, %VAL }], (isTwo imm:$VAL)), (apply [{MIR %root = MYTGT_DOUBLE %A }])>; Listing the C++ predicates like that will lead to a lot of repetitive and bug-prone code so it will also be possible to embed the predicates in custom variants of im...