search for: gimatchpredicate

...allow one node to be referenced in multiple places. I've kept the 'match' node at the top of the match to allow instructions and predicates to be freely combined within this section (see later examples). Without it, the stricter type checking on list<X> would require Instruction, GIMatchPredicate, and any future matching extensions to have a common base class. The explicit specification of root has also been removed in favour of a default value and a 'let' assignment to deal with any cases where the algorithm-chosen default is unsuitable (see the upside-down match section below). T...

...; think a generic heuristic based on frequency can solely solve the > > problem (i.e., what you're hinting in your RFC). > > That's something I'm intending to look into properly as part of the algorithm work. The syntax can support whatever mechanism we need for this through GIMatchPredicate subclasses and there's room for syntactic sugar by defining new operator classes. That's the kind of things that worries me. My cynical view makes me think that more syntactic sugar sounds like we develop a hack on top of the suggested syntax, thus I'm pushing for more forward thinking...

Hi Daniel, I finally read the proposal. I have a couple of comments that re-enforce what I was thinking initially: it is too early IMHO to develop a full tablegen backend for this. I believe we still miss ways to represent things that matters (see my comments below) and I am afraid we still don't know all that needs to be represented. > It can reach across basic blocks when it's safe

...allow one node to be referenced in multiple places. I've kept the 'match' node at the top of the match to allow instructions and predicates to be freely combined within this section (see later examples). Without it, the stricter type checking on list<X> would require Instruction, GIMatchPredicate, and any future matching extensions to have a common base class. > > Makes sense. > > I was wondering whether it also makes sense to allow eliding the (match) if it only has one child. It seems convenient, although having it always be required may reduce the learning curve There'...

...; think a generic heuristic based on frequency can solely solve the > problem (i.e., what you're hinting in your RFC). > > > That's something I'm intending to look into properly as part of the algorithm work. The syntax can support whatever mechanism we need for this through GIMatchPredicate subclasses and there's room for syntactic sugar by defining new operator classes. > > > That's the kind of things that worries me. My cynical view makes me > think that more syntactic sugar sounds like we develop a hack on top > of the suggested syntax, thus I'm pushing f...

...generic heuristic based on frequency can solely solve the > problem (i.e., what you're hinting in your RFC). > > > That's something I'm intending to look into properly as part of the > algorithm work. The syntax can support whatever mechanism we need for this > through GIMatchPredicate subclasses and there's room for syntactic sugar by > defining new operator classes. > > > That's the kind of things that worries me. My cynical view makes me > think that more syntactic sugar sounds like we develop a hack on top > of the suggested syntax, thus I'm push...

...here. I can pull them out into a separate 'outs' section. This has a flexibility cost since the user can no longer specify the complete argument order but that's probably a good thing for readability. >> Here's an example of a non-bool result: >> def reg_with_shift : GIMatchPredicate< >> (ins reg:$A), (outs uint64_t:$shift), MachineOperandPtr, [{ >> // MachineOperand *matchARMShiftedOp2(const MachineOperand &, uint64_t); >> return matchARMShiftedOp2(${A}, ${imm}); >> }]>; >> def : GICombineRule< >>...

...redTuple) between the current C++ equivalent for the match to the current C++ equivalent to the apply. Converting that into this tablegen syntax, we'd write: >> def extending_load_matchdata : GIDefMatchData<"PreferredTuple">; >> def extending_load_predicate : GIMatchPredicate< >> (ins reg:$A, extending_load_matchdata:$B), bool, [{ >> return Helper.matchCombineExtendingLoads(${A}, ${matchinfo}); > > I assume this was intended to be ${B} instead of ${matchinfo}? Yes, that's right. There's always at least one of these typos whe...

...o omit the formerly-anonymous names such as $t[0-3] in the above examples. Using an 'operand' typed variable as the def of an instruction does not change it to 'reg' but does emit the isReg() check that 'reg' would normally emit. Names used in an 'outs' position on a GIMatchPredicate are implicitly declared in the defs section using the type given by the predicate. Any names not given in the defs section are assumed to be 'instr' if they are used as a name for an operator that subclasses Instruction. This allows us to omit the defs for MI's involved in debug info. A...

...se is if %1 is a a scalar of at least s17. We're still not covering every type combination that we ought to though since %S and %D are still restricted to s8 and s16 respectively. To fix this, we'll need some custom predicates. A custom predicate is declared like so: def isScalarType : GIMatchPredicate<(ins type:$A), bool, [{ return ${A}.isScalar(); }]>; this declares that the predicate takes a type (LLT) named A and returns a bool. It also declares the code used to test the predicate and the place that the variable for A must be inserted. We can potentially use types other than b...

...bove examples. >> * Using an 'operand' typed variable as the def of an instruction >> does not change it to 'reg' but does emit the isReg() check that >> 'reg' would normally emit. >> 4. Names used in an 'outs' position on a GIMatchPredicate are >> implicitly declared in the defs section using the type given by the >> predicate. >> 5. Any names not given in the defs section are assumed to be 'instr' if >> they are used as a name for an operator that subclasses Instruction. >> This allow...