This is an archive of the discontinued LLVM Phabricator instance.

TableGen: Get rid of Init::getFieldInit
ClosedPublic

Authored by nhaehnle on Feb 21 2018, 2:45 AM.

Details

Summary

FieldInit will just rely on the standardized resolving mechanism to give
us DefInits for folding, thus simplifying the code.

Unlike the removal of resolveListElementReference, this shouldn't have
performance implications, because DefInits do not recurse inside their
record.

Change-Id: Id4544c774c9d9ee92f293615af6ecff706453f21

Diff Detail

Repository
rL LLVM

Event Timeline

nhaehnle created this revision.Feb 21 2018, 2:45 AM
tra added inline comments.Feb 22 2018, 10:11 AM
lib/TableGen/Record.cpp
1377 ↗(On Diff #135224)

assert(RV) as we no longer allow it to be nullptr.

nhaehnle added inline comments.Feb 22 2018, 3:40 PM
lib/TableGen/Record.cpp
1377 ↗(On Diff #135224)

Actually no, this is on purpose. resolveReferences works fine with RV == nullptr, it just has subtly different semantics (resolving via R.getValue() instead of resolving only RV). All the other recursive resolving calls look like this as well, e.g. when resolving the list in a VarListElementInit or operands of OpInit subclasses. The whole point of this change is to streamline the resolving process in FieldInit as well.

I haven't looked into the full history of this, but I suspect somebody mistakenly decided to skip the recursive resolveReferences call in the !RV call, and then somebody else added the special code in VarInit::getFieldInit to fix one particular case that ended up being broken by the lack of resolve calls.

Whatever the history, the Right Thing to do is for all composite Inits to recursively resolve their components in a standardized way. I have an upcoming change that does a similar thing with BitsInit.

nhaehnle added inline comments.Feb 22 2018, 3:41 PM
lib/TableGen/Record.cpp
1377 ↗(On Diff #135224)

That should have read: ... mistakenly decided to skip the recursive resolveReferences call in the !RV case.

Point is, VarInit::getFieldInit papers over this mistake in some specific cases but not all.

tra accepted this revision.Feb 23 2018, 10:50 AM
This revision is now accepted and ready to land.Feb 23 2018, 10:50 AM
This revision was automatically updated to reflect the committed changes.