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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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? |
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:
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 |
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 |
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?