This is an archive of the discontinued LLVM Phabricator instance.

TableGen: Allow NAME in template arguments in defm in multiclass
ClosedPublic

Authored by nhaehnle on Feb 22 2018, 4:17 PM.

Details

Summary

NAME has already worked for def in a multiclass, since the (protoype)
record including its NAME variable is created before parsing the
superclasses. Since defm's do not have an associated single record,
support for NAME has to be implemented differently here.

Original test cases provided by Artem Belevich (tra)

Change-Id: I933b74f328c0ff202e7dc23a35b78f3505760cc9

Diff Detail

Repository
rL LLVM

Event Timeline

nhaehnle created this revision.Feb 22 2018, 4:17 PM
tra added a comment.Feb 23 2018, 3:40 PM

I'm glad the tests work now, though I suspect it's mostly due to your other changes.

I'd replace the test cases with something that does not have unrelated things and only demonstrates that NAME can be used on the right hand side of def[m] : now.

It looks like use of NAME would also be allowed for def inside multiclass. If that's indeed the case, I'd change the description appropriately.

test/TableGen/MultiClass-defm-fail.td
16 ↗(On Diff #135551)

Presumably you wanted to replace s with NAME here and below to illustrate the effect of the patch.

nhaehnle updated this revision to Diff 135875.Feb 26 2018, 1:59 AM

Add test for NAME on the right-hand side of def in multiclass.

nhaehnle edited the summary of this revision. (Show Details)Feb 26 2018, 1:59 AM
In D43656#1018010, @tra wrote:

I'm glad the tests work now, though I suspect it's mostly due to your other changes.

I admit I haven't tested the change standalone on top of trunk, but I suspect it does work standalone.

I'd replace the test cases with something that does not have unrelated things and only demonstrates that NAME can be used on the right hand side of def[m] : now.

I've just added additional test cases for those, I think there is some use in keeping the other test cases around as well based on the experience I've had refactoring how records are instantiated (I haven't cleaned up those changes yet, they're to come later).

It looks like use of NAME would also be allowed for def inside multiclass. If that's indeed the case, I'd change the description appropriately.

Yes, and that part has more or less worked already without this change. I've updated the summary to note that.

test/TableGen/MultiClass-defm-fail.td
16 ↗(On Diff #135551)

Hmm, this is a negative test case, so I think it's actually beneficial that it doesn't depend on NAME: it should fail in the same way, whether or not NAME is supported.

tra accepted this revision.Feb 26 2018, 5:09 PM

Great! Thank you for including different uses of NAME inside a multiclass.

This revision is now accepted and ready to land.Feb 26 2018, 5:09 PM
This revision was automatically updated to reflect the committed changes.