This is an archive of the discontinued LLVM Phabricator instance.

TableGen: Add !dag function for construction
ClosedPublic

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

Details

Summary

This allows constructing DAG nodes with programmatically determined
names, and can simplify constructing DAG nodes in other cases as
well.

Also, add documentation and some very simple tests for the already
existing !con.

Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7

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:34 PM
docs/TableGen/LangIntro.rst
178 ↗(On Diff #137058)

Is it possible to construct a dag that has mix of dags and records as children? E.g (op1 (op11 a111, a112:$n112), a12) ? That is sometimes needsd to construct patterns where one of the arguments should be a dag (e.g. NVPTX uses a wrapper node for global symbols).

lib/TableGen/TGParser.cpp
1226 ↗(On Diff #137058)

The error should be more specific describing which argument is in error -- op, children or names (or operand index). Same in the RHS handling below.

nhaehnle updated this revision to Diff 137344.Mar 7 2018, 2:45 AM

Improve parser error messages and add missing CHECK: in tests

nhaehnle added inline comments.Mar 7 2018, 2:45 AM
docs/TableGen/LangIntro.rst
178 ↗(On Diff #137058)

Unfortunately, no. This is the weakness in the type system I think I've already mentioned elsewhere: since we don't have an any type, a list that mixes records and dags won't type-check. It would have to be a list<any>.

I think it makes sense to address that (although I haven't done so), but as a separate change.

lib/TableGen/TGParser.cpp
1226 ↗(On Diff #137058)

Good point, done. Note that the error will already point at the correct location of the operand (via the MHSLoc), but it's definitely true that a more explicit error can help avoid confusion.

tra added inline comments.Mar 7 2018, 10:55 AM
docs/TableGen/LangIntro.rst
178 ↗(On Diff #137058)

OK. We should probably then mention in the description that all children must be of the same type.
Speaking of which, would records of different types, but with shared ancestry be allowed? I assume they would.

test/TableGen/dag-functional.td
48 ↗(On Diff #137344)

Would there be a benefit of testing !dag with nodes being list<dag> or list<SomeClass> (and, possibly using records of different type, but inherited from SomeClass)?

nhaehnle updated this revision to Diff 137718.Mar 9 2018, 3:13 AM
nhaehnle marked an inline comment as done.

Clarify docs, add test cases.

nhaehnle added inline comments.Mar 9 2018, 3:38 AM
docs/TableGen/LangIntro.rst
178 ↗(On Diff #137058)

Yes, shared ancestry is possible. I'm adding an explanation.

test/TableGen/dag-functional.td
48 ↗(On Diff #137344)

Yes, makes sense. I'm adding those tests above.

tra accepted this revision.Mar 9 2018, 9:25 AM
This revision is now accepted and ready to land.Mar 9 2018, 9:25 AM
This revision was automatically updated to reflect the committed changes.