This is an archive of the discontinued LLVM Phabricator instance.

[GlobalIsSel] Allow using PatFrags with multiple defs as the root of a combine rule
ClosedPublic

Authored by Pierre-vh on Aug 11 2023, 3:24 AM.

Details

Summary

I had to tighten the restrictions on PatFrags a bit to make it consistent: instructions that
define the root of a PF can only have one def.

Diff Detail

Event Timeline

Pierre-vh created this revision.Aug 11 2023, 3:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 11 2023, 3:24 AM
Herald added a subscriber: StephenFan. · View Herald Transcript
Pierre-vh requested review of this revision.Aug 11 2023, 3:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 11 2023, 3:24 AM
Pierre-vh updated this revision to Diff 549322.Aug 11 2023, 3:31 AM

Document the new limitation

foad added inline comments.Aug 11 2023, 3:34 AM
llvm/include/llvm/Target/GlobalISel/Combine.td
163

This may be a silly question since I am not too familiar with PatFrags, and have no idea how they are implemented:

Why does a PatFrag like this have two defs, instead of one use and one def?

Pierre-vh marked an inline comment as done.Aug 11 2023, 3:42 AM
Pierre-vh added inline comments.
llvm/include/llvm/Target/GlobalISel/Combine.td
163

It's actually a design point I've been struggling with for a while, and the current iteration I've settled on (and that makes the most sense to me) is:

  • out operands are defined by some instruction in all alternatives of the PatFrag, they can only be machine operands
  • in operands are never defined by the patterns, they can be machine operands or immediates

Here the PatFrag defines $src so it's an out operand. If we wanted to also access $x that'd be an in operand because it's not defined by any instruction

Having $srrc as an out avoids having 2 defs that contradict each other, making the pattern impossible to match.

Another option could also be to always have a single def (the root) and just error when an inst is accidentally def'd twice with something like error: impossible pattern or something. Both have their pros and cons

arsenm added inline comments.Aug 17 2023, 5:54 AM
llvm/test/TableGen/GlobalISelCombinerMatchTableEmitter/patfrag-errors.td
266

It's somewhat confusing all the defs go to the right of the opcode name unlike in the actual mir

llvm/utils/TableGen/GlobalISelCombinerMatchTableEmitter.cpp
816

this could just return an ArrayRef?

Pierre-vh marked 2 inline comments as done.Aug 21 2023, 11:58 PM
Pierre-vh added inline comments.
llvm/test/TableGen/GlobalISelCombinerMatchTableEmitter/patfrag-errors.td
266

I agree, but not sure if we have an alternative unless we want to use something ugly like (pattern $foo, $z, G_UNMERGE_VALUES $y) everywhere because ($foo doesn't work I think?

I'm open to suggestions if you have a proposal with a better syntax, but IMO I think it's fine as-is. It's a small quirk of TableGen we have to deal with and unless we want to add some new TableGen syntax for infix/postfix operators, or parse MIR strings, we have to work with this

Pierre-vh marked 2 inline comments as done.

Use ArrayRef

arsenm accepted this revision.Aug 23 2023, 3:02 PM
This revision is now accepted and ready to land.Aug 23 2023, 3:02 PM