This is an archive of the discontinued LLVM Phabricator instance.

[tblgen][PredicateExpander] Add the ability to describe more complex constraints on instruction operands.
ClosedPublic

Authored by andreadb on Oct 30 2018, 12:03 PM.

Details

Summary

Before this patch, class PredicateExpander only knew how to expand simple predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to express checks like this one:

Foo(MI->getOperand(0).getImm()) == ExpectedVal;

Here, the immediate operand value at index zero is passed in input to function Foo, and ExpectedVal is compared against the value returned by function Foo.

While this predicate pattern doesn't show up in any X86 model, it shows up in other upstream targets. So, being able to support those predicates is fundamental if we want to be able to modernize all the scheduling models upstream.

With this patch, we allow users to specify if a register/immediate operand value needs to be passed in input to a function as part of the predicate check. Now, register/immediate operand checks all derive from base class CheckOperandBase.

This patch also changes where TIIPredicate definitions are expanded by the instructon info emitter. Before, definitions were expanded in class XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates expanded directly in XXXInstrInfo. That is because functions used by the new operand predicates may only exist in the derived class (i.e. XXXInstrInfo).

This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex scheduling predicates, and expose them to llvm-mca

Please, let me know if okay to commit,

Thanks,
-Andrea

Diff Detail

Event Timeline

andreadb created this revision.Oct 30 2018, 12:03 PM
mattd accepted this revision.Oct 30 2018, 12:45 PM

LGTM! Nice change!

utils/TableGen/PredicateExpander.cpp
24

Minor nit. You name the formal parameter as 'FunctionMapper' but the function decl names the same parameter 'FunctionExpander' Either name is fine (I prefer Expander).

This revision is now accepted and ready to land.Oct 30 2018, 12:45 PM
This revision was automatically updated to reflect the committed changes.