[PATCH] D83034: [GlobalISel] Don't skip adding predicate matcher
Daniel Sanders via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 6 12:54:22 PDT 2020
dsanders added a comment.
Could you add a test case or point us at a example of an existing test that goes wrong? The description in the commit message is unlikely to be the full story as we already cover loads with non-null MemoryVT's. My best guess is you are attempting to use builtin predicates and custom predicates together. I don't see a reason why that shouldn't be allowed but it's not something that was intended as the goal was aiming to fully remove the custom C++ from the tablegen headers so that tablegen could do some transformations on sextload/zextload and similar to fix DAGISel vs GlobalISel modelling mismatches.
================
Comment at: llvm/utils/TableGen/GlobalISelEmitter.cpp:3595-3605
// G_LOAD is used for both non-extending and any-extending loads.
if (Predicate.isLoad() && Predicate.isNonExtLoad()) {
InsnMatcher.addPredicate<MemoryVsLLTSizePredicateMatcher>(
0, MemoryVsLLTSizePredicateMatcher::EqualTo, 0);
continue;
}
if (Predicate.isLoad() && Predicate.isAnyExtLoad()) {
----------------
These two cases covered all of the loads with predicates that were moved to built-in predicates.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D83034/new/
https://reviews.llvm.org/D83034
More information about the llvm-commits
mailing list