[all-commits] [llvm/llvm-project] 1254f6: TableGen/GlobalISel: Partially fix nontrivial, cus...

Matt Arsenault via All-commits all-commits at lists.llvm.org
Tue Jul 14 11:27:10 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 1254f6d5312cd4952e413cc11dd7c78a87d050b9
      https://github.com/llvm/llvm-project/commit/1254f6d5312cd4952e413cc11dd7c78a87d050b9
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2020-07-14 (Tue, 14 Jul 2020)

  Changed paths:
    M llvm/test/TableGen/GlobalISelEmitter.td
    A llvm/test/TableGen/GlobalISelEmitterCustomPredicate.td
    M llvm/test/TableGen/GlobalISelEmitterOverloadedPtr.td
    M llvm/utils/TableGen/GlobalISelEmitter.cpp

  Log Message:
  -----------
  TableGen/GlobalISel: Partially fix nontrivial, custom predicates

Currently custom code predicates can only really be used for
contextless checks tied to a single instruction (e.g. check the def
for hasOneUse). If you do want to inspect the input instructions in
the source pattern, you cannot without re-verifying the opcode and
type checks implied by the patterns, since this check was emitted
before any operand constraints. Really, these are pattern level
predicates that implicitly depend on the instruction and operand
checks.

Introduce a filtering function so the custom predicate is emitted
last. I'm not sure this is the most elegant solution. It seems like
this is really a different thing from the InstructionMatcher/IPM_
predicate kinds. I initially tried keeping this in a separate
predicate list, but that also seemed awkward.

This only half fixes the problem I'm trying to solve. The AMDGPU
pattern I'm attempting to port also uses the PredicateCodeUsesOperands
feature to allow checks on the source operands when the input pattern
is commuted. Really the emitter should reject the pattern since it
doesn't handle this case, but at this point it would be more
productive to just implement this.




More information about the All-commits mailing list