This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Match table opt: fix a bug in matching num of operands
ClosedPublic

Authored by rtereshin on Oct 30 2019, 9:02 PM.

Details

Summary

If there is a dag node with a variable number of operands that has at
least N operands (for some non-negative N), and multiple patterns with
that node with different number of operands, we would drop the number of
operands check in patterns with N operands, presumably because it's
guaranteed in such case that none of the per-operand checks will access
the operand list out-of-bounds.

Except semantically the check is about having exactly N operands, not at
least N operands, and a backend might rely on it to disambiguate
different patterns.

In this patch we change the condition on emitting the number of operands
check from "the instruction is not guaranteed to have at least as many
operands as are checked by the pattern being matched" to "the
instruction is not guaranteed to have a specific number of operands".

We're relying (still) on the rest of the CodeGenPatterns mechanics to
validate that the pattern itself doesn't try to access more operands
than there is in the instruction in cases when the instruction does have
fixed number of operands, and on the machine verifier to validate at
runtime that particular MIs like that satisfy the constraint as well.

Diff Detail

Event Timeline

rtereshin created this revision.Oct 30 2019, 9:02 PM

Testcase?

Doesn't exist upstream. Match tables gain about one extra num operands' check (for G_INTRINSIC_W_SIDE_EFFECTS), but it doesn't affect the behavior as far as I can tell, as in those cases the number of operands semantically is in fact stable, just not evident from static properties of the generic opcode itself.

qcolombet accepted this revision.Oct 31 2019, 1:51 PM

For the test case, couldn't you add a isVariadic instruction with different patterns in one of the TableGen test?

Otherwise LGTM.

llvm/utils/TableGen/GlobalISelEmitter.cpp
2276

Stupid question: what complains if an instruction does not have the isVariadic attribute, but we write patterns with different number of operands?
(Just wondering if we need an assert that !isVariadic => getNumOperands() == OpcMatcher.getNumOperands()).

This revision is now accepted and ready to land.Oct 31 2019, 1:51 PM
rtereshin marked an inline comment as done.Oct 31 2019, 11:50 PM
rtereshin added inline comments.
llvm/utils/TableGen/GlobalISelEmitter.cpp
2276

Stupid question: what complains if an instruction does not have the isVariadic attribute, but we write patterns with different number of operands?

This does: https://github.com/llvm/llvm-project/blob/master/llvm/utils/TableGen/CodeGenDAGPatterns.cpp#L2414-L2420

(Just wondering if we need an assert that !isVariadic => getNumOperands() == OpcMatcher.getNumOperands()).

Considered the same, decided redundant.

rtereshin updated this revision to Diff 227408.Nov 1 2019, 2:14 AM

Added a TableGen test as requested, though, I'm quite convinced it wasn't worth the time and will be difficult to maintain.

rtereshin marked an inline comment as done.Nov 1 2019, 2:14 AM
This revision was automatically updated to reflect the committed changes.

Thanks for the test case!

llvm/utils/TableGen/GlobalISelEmitter.cpp
2276

Sounds good.