search for: g_trunc

...nymous // 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),...

...>> // 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)), >> (apply (G_ZEXT $D, $S))>; >...

...p 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 tblgen's DAG type. This avoids the restrictions o...

...different pseudo register banks used for operands that really function as booleans (select/br conditions, compare results, and a few intrinsics). These two banks physically alias the SGPR bank, but contextually function differently than an s1 value from a non-boolean source (e.g. a G_LOAD of s1 or G_TRUNC to s1). G_SELECT (s1 G_LOAD) would be illegal for example without inserting some kind of compare between the load and select boolean use. The primary problem I’m currently aiming to solve is losing this contextual pseudo-register bank information once an instruction is selected, as a virtual regis...

...ing in the middle of a match. This could be used in a similar way to the upside-down match above to control the insertion point and priority. For example: >>>> def : GICombineRule< >>>> (defs root:$root, reg:$A, reg:$B, reg:$C), >>>> (match [{MIR %1(s32) = G_TRUNC %A(s64) >>>> %2(s32) = G_TRUNC %B(s64) >>>> %root = G_ADD %1, %2 >>>> %C(s64) = G_SEXT %root }]), >>>> (emit [{MIR %root = G_ADD %A, %B >>>> %C = G_SEXT_INREG %root }])>; >...

...w we would declare Combine Rules in tablegen and with the help of the people credited above I think we'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 in...

...ce TableGen-generated instcombine passes? It would be nice to > re-use many of the rules, for example, except 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....

...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 matching names instead of tblgen's DAG type. This avoids t...

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

...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 >> _______________________________________________ >>...

...ally support the root being in the middle of a match. This could be used in a similar way to the upside-down match above to control the insertion point and priority. For example: >> def : GICombineRule< >> (defs root:$root, reg:$A, reg:$B, reg:$C), >> (match [{MIR %1(s32) = G_TRUNC %A(s64) >> %2(s32) = G_TRUNC %B(s64) >> %root = G_ADD %1, %2 >> %C(s64) = G_SEXT %root }]), >> (emit [{MIR %root = G_ADD %A, %B >> %C = G_SEXT_INREG %root }])>; >> Unfortunately, I don't have any...

...lap between the two as a lot of the G_* opcodes directly correspond to LLVM-IR instructions. The tricky bit will 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 w...

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".

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

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