via llvm-dev
2018-Jan-08 20:19 UTC
[llvm-dev] about AsmMatcherEmitter rules for setting matchables precedence
Hi, In AsmMatcherEmitter.cpp, the operator “<” for comparing matchables (MatchableInfo objects) only checks matches that require more features as the last rule. I would like to propose that we check for that rule earlier, in the case of unrelated UserClasses, before we decide to set precedence based on UserClass name. The motivation is that unrelated UserClasses seem to be Immediate Operand classes, at least in the test cases I am looking at. We usually do not define Immediate Operands as subclasses of others. When we set precedence by UserClass name we neglect the higher constraint imposed by the number of required features. And the required features are likely to affect immediate ranges. Something like the change below: (alternatively, we can move this change into the operator ‘<” for comparing ClassInfo). diff --git a/utils/TableGen/AsmMatcherEmitter.cpp b/utils/TableGen/AsmMatcherEmitter.cpp index 1a820a5..3be813e 100644 --- a/utils/TableGen/AsmMatcherEmitter.cpp +++ b/utils/TableGen/AsmMatcherEmitter.cpp @@ -594,6 +594,12 @@ struct MatchableInfo { // Compare lexicographically by operand. The matcher validates that other // orderings wouldn't be ambiguous using \see couldMatchAmbiguouslyWith(). for (unsigned i = 0, e = AsmOperands.size(); i != e; ++i) { + if (AsmOperands[i].Class->isUserClass() && + RHS.AsmOperands[i].Class->isUserClass() && + !AsmOperands[i].Class->isRelatedTo(*RHS.AsmOperands[i].Class)) + if (RequiredFeatures.size() != RHS.RequiredFeatures.size()) + return RequiredFeatures.size() > RHS.RequiredFeatures.size(); + if (*AsmOperands[i].Class < *RHS.AsmOperands[i].Class) return true; if (*RHS.AsmOperands[i].Class < *AsmOperands[i].Class) Do you see any problem with this change? Is there a way to make these rules target dependent so we can have more control on the auto-generated instruction matchables precedence? Thank you, Ana. -- Ana Pazos Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Reasonably Related Threads
- TableGen change in LLVM 3.9 allows only prefix instruction notation
- [LLVMdev] Hexagon Assembly parser question
- [LLVMdev] Hexagon Assembly parser question
- InstAlias with tied operands - can it be supported?
- [LLVMdev] [PATCH] Handle tied sub-operands in AsmMatcherEmitter