Page MenuHomePhabricator

[globalisel][tablegen] Import ComplexPattern when used as an operator
ClosedPublic

Authored by dsanders on Sep 5 2017, 1:24 AM.

Details

Summary

It's possible for a ComplexPattern to be used as an operator in a match
pattern. This is used by the load/store patterns in AArch64 to name the
suboperands returned by ComplexPattern predicate so that they can be broken
apart and referenced independently in the result pattern.

This patch adds support for this in order to enable the import of load/store
patterns.

Depends on D37445

Event Timeline

dsanders created this revision.Sep 5 2017, 1:24 AM
dsanders updated this revision to Diff 118454.Oct 10 2017, 12:35 PM

Rebase and ping

qcolombet accepted this revision.Oct 12 2017, 12:35 PM

Looks fine with one comment:
Do you think we need a new opcode in the state machine for that?

We could have reused ComplexRender with an additional parameter and use -1 to mean render all of them.
For the sake of optimization, the current patch is actually better, but in terms of simplicity I wonder.

Feel free to commit as is. That was just my 2c :).

This revision is now accepted and ready to land.Oct 12 2017, 12:35 PM

Looks fine with one comment:
Do you think we need a new opcode in the state machine for that?

We could have reused ComplexRender with an additional parameter and use -1 to mean render all of them.
For the sake of optimization, the current patch is actually better, but in terms of simplicity I wonder.

Feel free to commit as is. That was just my 2c :).

At the moment, I'm leaning towards separate opcodes on the basis that the we shouldn't make the common case longer to account for the rare case. However, the trade-off will be harder once we start trying to compress the table. Right now, opcodes are cheap since we have 2^32 of them but they'll be more valuable if we only have 2^8.

I think we should note this down as something to evaluate when we compress the table.

dsanders closed this revision.Oct 15 2017, 10:03 AM