[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