This is an archive of the discontinued LLVM Phabricator instance.

TableGen: Add a defset statement
ClosedPublic

Authored by nhaehnle on Mar 5 2018, 12:19 PM.

Details

Summary

Allows capturing a list of concrete instantiated defs.

This can be combined with foreach to create parallel sets of def
instantiations with less repetition in the source. This purpose is
largely also served by multiclasses, but in some cases multiclasses
can't be used.

The motivating example for this change is having a large set of
intrinsics, which are generated from the IntrinsicsBackend.td file
included by Intrinsics.td, and a corresponding set of instruction
selection patterns, which are generated via the backend's .td files.

Multiclasses cannot be used to eliminate the redundancy in this case,
because a multiclass cannot span both LLVM's common .td files and
the backend .td files at the same time.

Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b

Diff Detail

Repository
rL LLVM

Event Timeline

nhaehnle created this revision.Mar 5 2018, 12:19 PM
tra added inline comments.Mar 6 2018, 1:07 PM
docs/TableGen/LangRef.rst
360–368 ↗(On Diff #137057)

Does it mean that instantiating any record that is not of type A will be an error? That sounds rather limiting.
That would prevent use of anonymous records or non-anonymous records or different types we may want to instantiate within the same multiclass hierarchy without having to duplicate all of it.

Could we change the semantics to the list collects all instantiated records of type A and, maybe, allow more than one pair of type:list , so we can collect multiple record types?

Another approach would be to say -- give me all records of type A, created by this defm instance. I.e. instead of defset A foo = { records } you do something like defm FOO : M<...>; list<A> foo = !defset(FOO).

nhaehnle updated this revision to Diff 137343.Mar 7 2018, 2:43 AM

Clarify the docs

docs/TableGen/LangRef.rst
360–368 ↗(On Diff #137057)

Anonymous (or rather "inline"?) records are not an issue: they are created on a different path and never added to a defset, and I think they shouldn't be. I've clarified that.

I did make incompatible (non-anonymous) record types an error because one could accidentally make the type of list<A> too strict and then end up with records silently not being collected in surprising ways.

I see your point about allowing different types explicitly, but I'm not entirely convinced yet. In part the whole point of defset is that it helps avoid reducing duplication by using the resulting list in a foreach later. I'm also a bit hesitant about proliferation of defset, and I'd personally err on the side of starting with stricter semantics. It's always easier to go to looser semantics later if good use cases for it show up than the other way around.

tra accepted this revision.Mar 7 2018, 10:43 AM
tra added inline comments.
docs/TableGen/LangRef.rst
360–368 ↗(On Diff #137057)

Fair enough. I don't have any specific use case for multiple types of records inside defset and if anonymous records are allowed, this leaves some flexibility for what could be done inside the defset.

I'm OK with this variant. It should indeed be reasonably easy to extend if/when we have specific use cases.

This revision is now accepted and ready to land.Mar 7 2018, 10:43 AM
This revision was automatically updated to reflect the committed changes.