search for: g_zext

...defs related to rule 3 since these are the formerly anonymous // operands that now need names to fit into the tblgen dag type // Omitted due to rule 4 // Omitted due to rule 5 // Omitted due to rule 6 def : GICombineRule<(defs reg:$D, reg:$S), (match (G_ZEXT s32:$t1, s8:$S), (G_TRUNC s16:$D, s32:$t1)), (apply (G_ZEXT s16:$D, s8:$S))>; def : GICombineRule<(defs reg:$D, reg:$S), (match (G_ZEXT $t1, $S), (G_TRUNC $D, $t1),...

...these are the formerly anonymous >> // operands that now need names to fit into the tblgen dag type >> // Omitted due to rule 4 >> // Omitted due to rule 5 >> //Omitted due to rule 6 >> def : GICombineRule<(defs reg:$D, reg:$S), >> (match (G_ZEXT s32:$t1, s8:$S), >> (G_TRUNC s16:$D, s32:$t1)), >> (apply (G_ZEXT s16:$D, s8:$S))>; >> def : GICombineRule<(defs reg:$D, reg:$S), >> (match (G_ZEXT $t1, $S), >> (G_TRUNC $D, $t1), >> (isScalarType type:$D), >> (isLargerType type:$D, type:$S)), >&gt...

...ven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S), (match (G_ZEXT s32:$t1, s8:$S), (G_TRUNC s16:$D, s32:$t1)), (apply (G_ZEXT s16:$D, s8:$S))>; This has been converted to the style that fits within tblgen's DAG type but isn't (directly) a DAG. The DAG structure is defined by the matching names instead of...

...39;ve ended up somewhere that should be nice to work with and opens up a lot of possibilities. Individual Combine Rules A Simple Example Here's a simple example that eliminates a redundant G_TRUNC. def : GICombineRule<(defs root:$D, operand:$S), (match [{MIR %1(s32) = G_ZEXT %S(s8) %D(s16) = G_TRUNC %1(s32) }]), (apply [{MIR %D(s16) = G_ZEXT %S(s8) }])>; There's three parts to this rule: defs declares the interface for the rule. The definitions in the defs section are the glue between the Combine algorithm an...

...result (type0) legalized as legal for s32 (corresponding to plan a)). We would get similar final output (also correct) if we said that type0 is legal for s1 (corresponding to b), but in this case it is also necessary to: tell that extends are legal for {s32, s1}, regbankselct and instruction select G_ZEXT. It would be nice to have a place around legalizer where we could combine extending artifacts with some instructions, as combining instruction with G_AND (or some other bitwise instr) seem like much more work later that could be done earlier. Its better to not produce superfluous extend (bitwise i...

...;>> // of $dst >>> def : GICombineRule< >>> (defs root:$dst, operand:$src0, operand:$src1), >>> (oneof (ginst i16:$dst, i16:$src0, i16:$src1), >>> (match (ginst i16:$tmp, i16:$src0, i16:$src1), >>> (G_ZEXT i32:$dst, $tmp))), >>> (inst $dst, $src0, $src1)>; >>> >>> // A third rule for zext to 64 bits would go here... >>> } >> This is the reason that macros are explicitly imported in the defs section and the imported instances are renameable. The s...

...they'd match LLVM IR > rather than MIR. As you go about implementation, maybe keep this idea > in mind? > > > Here's a simple example that eliminates a redundant G_TRUNC. > > > > def : GICombineRule<(defs root:$D, operand:$S), > > (match [{MIR %1(s32) = G_ZEXT %S(s8) > > %D(s16) = G_TRUNC %1(s32) }]), > > (apply [{MIR %D(s16) = G_ZEXT %S(s8) }])>; > > The use of '%' vs. '$' here really threw me for a loop. I would have > expected '$D' and '$S' everywhere. What's the significance of '%'...

...folds at the same time as CSE'ing. I just had a quick look at them and it seems we only constant fold binary operations. I just asked Aditya (who added it) about this and the main issue is identifying that a new G_CONSTANT is legal for unary operations that change the type of the constant like G_ZEXT/G_SEXT/G_TRUNC. >> Is there supposed to be a constant folding pass before Instruction Selection? CSE does not fold past unaries applied to operands, I'm surely missing a pass somewhere... >> >> Thanks, >> - Alex Davies >> _________________________________________...

...oving the vector type to a different unmerge source. My questions are : What is AArch64 doing with all of its legalization rules when they don’t seem to actually be implemented? Is the target selector supposed to be responsible for handling G_UNMERGE_VALUES/G_MERGE_VALUES/G_EXTRACT/G_INSERT/G_SEXT/G_ZEXT/G_ANYEXT for any strange type source, assuming the extra high bits over the LLT type are undefined or appropriately extended? For vectors, is any arbitrary vector only supposed to be legalized to a certain number of elements, and the target is supposed to treat this as N registers with possibly und...

...t defined one yet, but I don't see any reason we couldn't define non-operands in a similar way. >> _Macros_ >> _ >> _ >> I simplified the previous example a bit. Rather than only matching a G_LOAD, the current rule in AArch64 can match any of G_LOAD, G_SEXTLOAD, and G_ZEXTLOAD. We need some means to match one of several alternatives as well as collect and re-use common subpatterns. I've yet to look into how this would be practically implemented and this section is a bit vague as a result but here's the current thinking on how it should look and behave: >&g...

...l be the escape hatches into C++ would need to either have Instruction/MachineInstr versions or would need to accept both. >> Here's a simple example that eliminates a redundant G_TRUNC. >> >> def : GICombineRule<(defs root:$D, operand:$S), >> (match [{MIR %1(s32) = G_ZEXT %S(s8) >> %D(s16) = G_TRUNC %1(s32) }]), >> (apply [{MIR %D(s16) = G_ZEXT %S(s8) }])>; > > The use of '%' vs. '$' here really threw me for a loop. I would have > expected '$D' and '$S' everywhere. What's the significance of '%'...

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

...all, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. > > That's awesome :) > > >> _A Simple Example_ >> def : GICombineRule<(defs reg:$D, reg:$S), >> (match (G_ZEXT s32:$t1, s8:$S), >> (G_TRUNC s16:$D, s32:$t1)), >> (apply (G_ZEXT s16:$D, s8:$S))>; >> This has been converted to the style that fits within tblgen's DAG type but isn't (directly) a DAG. The DAG structure is defined by the...

Hi all, I'm trying to get GlobalISel up and running on an off-tree architecture and am thinking I must be doing something wrong, given by how few things actually work. Namely, any ImmLeaf pattern will fail to match if there is a (TRUNC/ZEXT/SEXT) applied to the constant operand, all of which are commonly created through Legalization. This is due to G_CONSTANT being explicitly looked for by