Commit Graph

2 Commits

Author SHA1 Message Date
Matt Arsenault 1254f6d531 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.
2020-07-14 14:26:51 -04:00
Jessica Paquette 5c8a29fe01 Teach GlobalISelEmitter to treat used iPTRAny operands as pointer operands
Overloaded intrinsics can use iPTRAny in used/input operands.

The GlobalISelEmitter doesn't know that these are pointers, so it treats them
as scalars. As a result, these intrinsics can't be imported.

This teaches the GlobalISelEmitter to recognize these as pointers rather than
scalars.

Differential Revision: https://reviews.llvm.org/D65756

llvm-svn: 369455
2019-08-20 22:04:10 +00:00