This is an archive of the discontinued LLVM Phabricator instance.

[WIP][GlobalISel] Combiner Intrinsic Matching
AbandonedPublic

Authored by Pierre-vh on May 16 2023, 6:07 AM.

Details

Summary

Adds support for matching intrinsics in a match pattern in the combiner.
They can be matched using the same syntax as the DAG patterns, i.e.

(match (int_foo_intrinsic $d))

Current issues with the impl:

  • Intrinsics cannot (yet) be used as leaf nodes if the previous node is a "fully-testable" node (e.g. a simple opcode match).

Solves #62628 (https://github.com/llvm/llvm-project/issues/62628)

Diff Detail

Event Timeline

Pierre-vh created this revision.May 16 2023, 6:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2023, 6:07 AM
Pierre-vh requested review of this revision.May 16 2023, 6:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2023, 6:07 AM

It's not quite ready yet, but I need some help, so I'm leaving this as a WIP and just adding a few reviewers until the two issues highlighted are sorted out.
Once these are addressed I will add more reviewers + more testcases (including practical ones, e.g. add patterns using intrinsics in AMDGPU combiner) for a proper review.

llvm/test/TableGen/GICombinerEmitter/match-tree.td
373

Is it possible to de-duplicate this with the current MatchDag?

llvm/utils/TableGen/GlobalISel/GIMatchTree.cpp
462

This is the most annoying bit at the moment. It's quite restrictive and the example in the github issue doesn't work because of it: https://github.com/llvm/llvm-project/issues/62628

I'm finding the lack of equivalent of ComplexPatterns and PatFrags to be frustrating. Should there be a new intermediate pattern source class to abstract over instructions?

llvm/test/TableGen/GICombinerEmitter/match-tree.td
35

Should have one that has side effects and one that doesn't to cover both G_INTRINSIC* cases.

Also, maybe try one with multiple return values. Should theoretically be matchable

llvm/utils/TableGen/GICombinerEmitter.cpp
64

These are supposed to use StringLiteral

arsenm added inline comments.May 16 2023, 6:16 AM
llvm/utils/TableGen/GlobalISel/GIMatchTree.cpp
462

Something is wrong with this "fully tested" code. It seems to just be wrong and mis-reports errors for cases which do match in the generated code (which is properly produced0

Pierre-vh added inline comments.May 17 2023, 12:14 AM
llvm/test/TableGen/GICombinerEmitter/match-tree.td
35

Will do, but about the G_INTRINSIC* case:
Currently I match both G_INTRINSIC and G_INSTRINC_W_SIDE_EFFECTS for any intrinsic. Is that the correct behaviour?

I did a quick look around in the tests, and I think they're interchangeable and we can't use whether the intrinsic has side effects or not to deduce the opcode to use, right? It's just that the "normal" opcode can be removed if it's unused, but the second one cannot because it's considered to have side effects?

llvm/utils/TableGen/GlobalISel/GIMatchTree.cpp
462

Indeed, I think it's not entirely right. I will take a deeper look at it but I also hope @dsanders can help here :)

I'm finding the lack of equivalent of ComplexPatterns and PatFrags to be frustrating. Should there be a new intermediate pattern source class to abstract over instructions?

These intrinsic patterns basically work as (match opcode + run c++ match logic) so we could definitely piggyback on top of it when it lands to add complex patterns that match any opcode + some C++ logic

Pierre-vh updated this revision to Diff 522964.May 17 2023, 2:20 AM
Pierre-vh marked 2 inline comments as done.

Address some comments, add multi ret test, add checking for number of arguments in instructions & intrinsics

Pierre-vh added inline comments.May 17 2023, 2:55 AM
llvm/utils/TableGen/GlobalISel/GIMatchTree.cpp
462

I just tried removing the error, but then I hit a crash in applyForPartition (Assertion Idx < Size && "Out-of-bounds Bit access."' failed.`) so I'm guessing there's indeed something wrong with the match tree

arsenm added inline comments.May 19 2023, 11:21 AM
llvm/test/TableGen/GICombinerEmitter/match-tree.td
35

I'd say more no than yes. There's a narrow set of cases where you could conceivably use G_INTRINSIC based on callsite attributes for a normally G_INTRINSIC_W_SIDE_EFFECTS. The DAG does not support this case. Off the top of my head the only cases where we could care about this are because of the limitations of buffer load intrinsics

TLDR not interchangeable

Pierre-vh added inline comments.May 22 2023, 2:37 AM
llvm/test/TableGen/GICombinerEmitter/match-tree.td
35

Are there any case where they could be interchangeable or not?

If not then I can just make the Intrinsic predicate a subclass of the "Opcode" predicate instead of "OneOfOpcode" predicate. It'll also fix one of my 2 issues which is duplicated code for both G_INTRINSIC instructions.

However if we think we may want to be able to match both G_INTRINSIC opcode for one pattern, then I can leave it in. I wouldn't be surprised if we see more G_INTRINSIC variants pop up so maybe there'll be a case down the line to handle 2+ opcodes for some kinds of intrinsics.

arsenm added inline comments.May 22 2023, 1:58 PM
llvm/test/TableGen/GICombinerEmitter/match-tree.td
35

The only case would be if we want to use callsite attributes to optimize opcode properties, but the only cases where we might want that are kind of workarounds. I wouldn't try to support that now

Pierre-vh marked 2 inline comments as done.

Address comments, handle side effect intrinsics
Now the last big issue is with reachability/leaf nodes.

Pierre-vh edited the summary of this revision. (Show Details)May 23 2023, 12:54 AM
Pierre-vh planned changes to this revision.Jun 19 2023, 12:19 AM

Waiting to see if https://discourse.llvm.org/t/rfc-matchtable-based-globalisel-combiners/71457 makes it or not, if it does, then this will be abandoned.

Pierre-vh abandoned this revision.Jul 11 2023, 3:42 AM

Needs to be rewritten for new combiner