This is an archive of the discontinued LLVM Phabricator instance.

TableGen/ISel: Allow PatFrag predicate code to access captured operands
ClosedPublic

Authored by nhaehnle on Sep 12 2018, 9:53 AM.

Details

Summary

This simplifies writing predicates for pattern fragments that are
automatically re-associated or commuted.

For example, a followup patch adds patterns for fragments of the form
(add (shl $x, $y), $z) to the AMDGPU backend. Such patterns are
automatically commuted to (add $z, (shl $x, $y)), which makes it basically
impossible to refer to $x, $y, and $z generically in the PredicateCode.

With this change, the PredicateCode can refer to $x, $y, and $z simply
as Operands[i].

Test confirmed that there are no changes to any of the generated files
when building all (non-experimental) targets.

Change-Id: I61c00ace7eed42c1d4edc4c5351174b56b77a79c

Diff Detail

Repository
rL LLVM

Event Timeline

nhaehnle created this revision.Sep 12 2018, 9:53 AM

I'm somewhat confused by the motivation. Can you explain why the fact that the operands are commuted causes a problem. In D51995, you just seem to be looping over them anyway.

RKSimon resigned from this revision.Sep 29 2018, 2:51 AM
RKSimon added a reviewer: kparzysz.

I'm somewhat confused by the motivation. Can you explain why the fact that the operands are commuted causes a problem. In D51995, you just seem to be looping over them anyway.

Sorry, I missed this. The issue is as follows; we're trying to match expressions like (add (add A, B), C). Indeed, we want to loop over A, B, and C!

The issue is that TableGen automatically generates commuted patterns, so we might also match an expression like (add A, (add B, C)). The C++ code in the PatFrag has no way of knowing which of these versions we actually matched. So with only access to the top-level node, there's no way to loop over A, B, and C without effectively duplicating the pattern matching that was already done for that.

And even if we did duplicate the matching in C++, we wouldn't actually have a guarantee that what we're doing is correct! For example, if the top level node is actually (add (add A, B), (add C, D)), then there's no way of knowing which of the children of the top-level add we should consider as black boxes, so we don't know whether to loop over A, B, and (add C, D) or whether to loop over (add A, B), C, and D.

rampitec accepted this revision.Nov 29 2018, 7:06 AM

As far as I understand if PredicateCodeUsesOperands is not used nothing changes.
LGTM.

This revision is now accepted and ready to land.Nov 29 2018, 7:06 AM
This revision was automatically updated to reflect the committed changes.