search for: g_sub

...aluation order happened 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...

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

...er not to discuss in this RFC. Assuming the underlying algorithm gains support for this, this is how the syntax would look: >> def : GICombineRule< >> (defs root:$root1, root:$root2, reg:$A, reg:$B), >> (match [{MIR %root1 = G_ADD %A, %B }], >> [{MIR %root2 = G_SUB %A, %B }]), >> (emit [{MIR %root1, %root2 = BUTTERFLY %A, %B }])>; >> This would match a G_ADD and G_SUB with operands in common and combine them into a BUTTERFLY operation. You can think of this as two normal rules, one with %root1 as the root and the other with %root2 as the root...

...algorithm changes which I'd prefer not to discuss in this RFC. Assuming the underlying algorithm gains support for this, this is how the syntax would look: def : GICombineRule< (defs root:$root1, root:$root2, reg:$A, reg:$B), (match [{MIR %root1 = G_ADD %A, %B }], [{MIR %root2 = G_SUB %A, %B }]), (emit [{MIR %root1, %root2 = BUTTERFLY %A, %B }])>; This would match a G_ADD and G_SUB with operands in common and combine them into a BUTTERFLY operation. You can think of this as two normal rules, one with %root1 as the root and the other with %root2 as the root. Grouping and Or...

...G_ADD $D, $t1, $t2) (G_SEXT s64:$C, $D)), (apply (G_ADD $D, $A, $B), (G_SEXT_INREG $C, $D))> { let MatchStartsFrom = (roots $D); }; def : GICombineRule< (defs reg:$D1, reg:$D2, reg:$A, reg:$B), (match (G_ADD $D1, $A, $B), (G_SUB $D2, $A, $B)), (apply (BUTTERFLY $D1, $D2, $A, $B))>; 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)))>;...

...(G_SEXT s64:$C, $D)), >> (apply (G_ADD $D, $A, $B), >> (G_SEXT_INREG $C, $D))> { >> let MatchStartsFrom = (roots $D); >> }; >> def : GICombineRule< >> (defs reg:$D1, reg:$D2, reg:$A, reg:$B), >> (match (G_ADD $D1, $A, $B), >> (G_SUB $D2, $A, $B)), >> (apply (BUTTERFLY $D1, $D2, $A, $B))>; >> 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...

...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 in perf...

...ssuming the underlying algorithm gains support for this, this is how the syntax would look: >>>> def : GICombineRule< >>>> (defs root:$root1, root:$root2, reg:$A, reg:$B), >>>> (match [{MIR %root1 = G_ADD %A, %B }], >>>> [{MIR %root2 = G_SUB %A, %B }]), >>>> (emit [{MIR %root1, %root2 = BUTTERFLY %A, %B }])>; >>>> This would match a G_ADD and G_SUB with operands in common and combine them into a BUTTERFLY operation. You can think of this as two normal rules, one with %root1 as the root and the other with %r...

...is 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 instruct...

...), (apply (G_ADD $D, $A, $B), (G_SEXT_INREG $C, $D))> { let MatchStartsFrom = (roots $D); }; Multiple roots All the changes in this section have already been discussed above: def : GICombineRule< (defs reg:$D1, reg:$D2, reg:$A, reg:$B), (match (G_ADD $D1, $A, $B), (G_SUB $D2, $A, $B)), (apply (BUTTERFLY $D1, $D2, $A, $B))>; $D1 and $D2 are both automatically chosen as roots since they are def'd but not used. Subregisters This is a new example based on our discussion about MIR having direct support for subregisters. We use subregister indexes to specify t...

...is 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 instruct...