search for: g_add

...:$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, $t1, $C)), (apply (create_imm [{ 2 * ${B}->getZExtValue() }], apint_value:$B):$NB, (G_ADD $t1, $A, $A), (G_ADD $D, $t1, $NB))>; // $D is needed because we wanted operand instead of reg. We could rewrite the predicate to...

...uses was an generic floating point instruction should not be an option for legalizer. Since GlobalISel Legalizer cannot distinguish between them using only LLT, only other option that I can see at this moment is having "F" variant of the generic instruction (like this is the case with G_ADD and G_FADD). Is this change possible? Or are there some other approaches for dealing with this problem? Petar

...:$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, $t1, $C)), >> (apply (create_imm [{ 2 * ${B}->getZExtValue() }], apint_value:$B):$NB, >> (G_ADD $t1, $A, $A), >> (G_ADD $D, $t1, $NB))>; >> // $D is needed because we wanted operand instead of reg. We could rewrite the predicate to...

Hi Daniel, On 13.09.2018. 19:32, Daniel Sanders wrote: > Could you clarify what you mean here? The new legalizer info can > define this with: >     getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32) > so I'm guessing you mean that code to mutate the G_SELECT is currently > missing Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't do that

...reg:$D, reg:$A, imm_2:$VAL), (match (G_MUL $D, $A, $VAL)), (apply (MYTGT_DOUBLE $D, $A))>; And here's the example that replaces 2 * (A + B) with 2A + 2B: def : GICombineRule< (defs reg:$D, reg:$A, imm:$B, imm_2:$C), (match (G_ADD $t1, $A, $B), (G_MUL $D, $t1, $C)), (apply (create_imm [{ 2 * ${B}->getZExtValue() }], apint_value:$B):$NB, (G_ADD $t1, $A, $A), (G_ADD $D, $t1, $NB))>; Passing arbitrary data from match to apply The main change in this section that hasn't al...

...plication 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 relative order that ge...

...>> // MachineOperand *matchARMShiftedOp2(const MachineOperand &, uint64_t); >> return matchARMShiftedOp2(${A}, ${imm}); >> }]>; >> def : GICombineRule< >> (defs root:$D, reg:$S1, reg_with_shift:$S2), >> (match [{MIR %D = G_ADD %S1, %S2 }]), >> (apply [{MIR %D = ADD %S1, %S2, %S2.shift }])>; >> (I've just realized there's a gap in the ability to name metadata when used in this way. I've gone with 'S2.shift' for now) >> This is equivalent to: >> def reg_with_shift :...

...in the result and modify them. This works the same way as registers. Here's an example of using the immediate in the apply step in a rule that replaces 2 * (A + B) with 2A + 2B: def : GICombineRule< (defs root:$root, reg:$A, imm:$B, imm_2:$C), (match [{MIR %1 = G_ADD %A, %B %root = G_MUL %1, %C }]), (apply [{MIR %1 = G_ADD %A, %A %2 = G_ADD %B, %B %root = G_ADD %1, %2 }])>; and of course, we'd also want to constant fold the 2B which is achieved in this rule by creating a new operand...

...reg:$A), (outs uint64_t:$shift), MachineOperandPtr, [{ // MachineOperand *matchARMShiftedOp2(const MachineOperand &, uint64_t); return matchARMShiftedOp2(${A}, ${imm}); }]>; def : GICombineRule< (defs root:$D, reg:$S1, reg_with_shift:$S2), (match [{MIR %D = G_ADD %S1, %S2 }]), (apply [{MIR %D = ADD %S1, %S2, %S2.shift }])>; (I've just realized there's a gap in the ability to name metadata when used in this way. I've gone with 'S2.shift' for now) This is equivalent to: def reg_with_shift : GIMatchPredicate< (ins...

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

...isters. We use subregister indexes to specify that it's a subregister that should be emitted by the apply step. >> def : GICombineRule< >> (defs reg:$D, reg:$A, reg:$B), >> (match (G_TRUNC s32:$t1, s64:$A), >> (G_TRUNC s32:$t2, s64:$B), >> (G_ADD $D, $t1, $t2), >> (apply (ADD32 $D, (sub_lo $A), (sub_lo $B)))>; >> _Matching MachineMemOperands_ >> While re-writing these examples, I also realized I didn't have any examples for testing properties of the MachineMemOperand, so here's one: >> def mmo_is_loa...

...ons are legal, 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...

...HALF (1 << (SCALEBITS - 1)) -#define FIX(x) ((int) ((x) * (1<<SCALEBITS) + 0.5)) -#define CONVERT(r, g, b, y, u, v) G_STMT_START{ \ - int cb = (u) - 128;\ - int cr = (v) - 128;\ - int cy = (y) << SCALEBITS;\ - int r_add = cy + FIX(1.40200) * cr + ONE_HALF;\ - int g_add = cy - FIX(0.34414) * cb - FIX(0.71414) * cr + ONE_HALF;\ - int b_add = cy + FIX(1.77200) * cb + ONE_HALF;\ - r_add = CLAMP (r_add, 0, 255 << SCALEBITS);\ - g_add = CLAMP (g_add, 0, 255 << SCALEBITS);\ - b_add = CLAMP (b_add, 0, 255 << SCALEBITS);\ - r = r_add >&...

...egalize 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 t...

...egalize 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 t...

Hello, I am developing GlobalISel for MIPS. I have a few questions and observations about defining legality of generic instruction and also possible combining of instructions and artifacts in pre/post legalizer combiner or elsewhere (e.g. in some sort of instruction-select patterns). I look at legality as "If generic instruction can be selected into machine instruction, it is legal".