search for: g_sext

...ive us fewer instructions to work with and carry on in later passes. It would let us select extend in instruction-select. This approach could result in using a little less memory. Also some mips processors have instructions that extract bits or do sign extend. These could be selected from G_ZEXT or G_SEXT generating single instruction instead of two equivalent bitwise instructions. Q: I see that there is a plan to add pre/post legalizer combining pass. Where should combining happen, in pre/post legalizer combining pass or in the instruction select pass? For example, G_SELECT could be selected into...

...le. I haven'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 an...

...R %1, %0 # We don't actually have a rotate right at the moment so this would have to match the equivalent and/shift/or sequence %0 = G_CONSTANT iN 1 %2 = G_ROR %1, %0 # We don't actually have a rotate right at the moment so this would have to match the equivalent and/shift/or sequence %3 = G_SEXT %2 %2 = G_[AL]SHR %0, %1 %2 = G_SHL %0, %1 %2 = G_ROR %0, %1 # We don't actually have a rotate right at the moment so this would have to match the equivalent and/shift/or sequence I don't think it's strictly necessary to escape into C++ for this case (except for checking the immedia...

...GE_VALUES, but also G_EXTRACT/G_INSERT and conversion instructions) and what the contract between the legalizer and selector actually is. For scalar values, things seem clearer, but I’m still confused. The AArch64 selector code seems content to allow strange sized values in the source of G_EXTRACT/G_SEXT etc, and then just set the register class as the type information isn’t really needed anymore. However, it also defines a more restricted set of legal types, but the legalizations are not implemented. Similarly quite a lot of legalization rules defined for merge/unmerge (an ~88 line block), but aga...

...hinfo)>; // I haven't included any rules for omitting defs from GIMacro but I can look into this if we want. def ANYLOAD : GIMacro<(defs def:$R, use:$S, uint64_t:$IDX), (match (oneof (match (G_LOAD $R, $S)), (match (G_SEXTLOAD $R, $S)), (match (G_ZEXTLOAD $R, $S))):$IDX>; // $ANYLOAD is needed to import the macro and name its instance def extending_loads : GICombineRule< (defs reg:$D, reg:$A, extending_load_matchdata:$matchinfo, ANYLOAD:$ANYLOAD), (mat...

...ntirety of the replacement so we escape into arbitrary C++ instead and arrange for the variables to be injected appropriately using the 'exec' operator. 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 an...

...$D, extending_load_matchdata:$matchinfo)>; >> // I haven't included any rules for omitting defs from GIMacro but I can look into this if we want. >> def ANYLOAD : GIMacro<(defs def:$R, use:$S, uint64_t:$IDX), >> (match (oneof (match (G_LOAD $R, $S)), >> (match (G_SEXTLOAD $R, $S)), >> (match (G_ZEXTLOAD $R, $S))):$IDX>; >> // $ANYLOAD is needed to import the macro and name its instance >> def extending_loads : GICombineRule< >> (defs reg:$D, reg:$A, extending_load_matchdata:$matchinfo, ANYLOAD:$ANYLOAD), >>...

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

...checking on 'dag' compared to 'list<X>' allows us to freely mix DAG-style matches and predicates. def ANYLOAD : GIMacro<(defs def:$R, use:$S, uint64_t:$IDX), (match (oneof (match (G_LOAD $R, $S)), (match (G_SEXTLOAD $R, $S)), (match (G_ZEXTLOAD $R, $S))):$IDX>; def extending_loads : GICombineRule< (defs reg:$D, reg:$A, extending_load_matchdata:$matchinfo, ANYLOAD:$ANYLOAD), (match (ANYLOAD $D, $A), (extending_load_predicate operand:...

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

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