This is an archive of the discontinued LLVM Phabricator instance.

TableGen: Use DefInit::getDef() instead of the type's getRecord()
ClosedPublic

Authored by nhaehnle on Feb 23 2018, 7:50 AM.

Details

Summary

The former simply makes more sense: we want to access the data here in
the backend, not information about the type.

More importantly, removing users of RecordRecTy::getRecord() allows us
more freedom to refactor the frontend.

Change-Id: Iee8905fd22cdb9b11c42ca03246c03d8fe4dd77f

Diff Detail

Event Timeline

nhaehnle created this revision.Feb 23 2018, 7:50 AM
tra added a comment.Feb 23 2018, 11:08 AM

The change looks good to me, but you should get OK from someone familiar with the back-end.

Thanks. It's hard to say who really groks utils/TableGen/FixedLenCodeEmitter.cpp, adding some folks (+ @arsenm) who at least wrote the bits near my changes.

I've verified that this change doesn't change the generated code in any of the backends in trunk at all.

The basic pattern is simple: use cast<DefInit>(TI)->getDef() instead of cast<RecordRecTy>(TI->getType())->getRecord(). If TI is a DefInit, those will yield the same result. If TI is not a DefInit, then the former will crash and the latter will return the record representing some uninstantiated class, which is not meaningful.

So I'd say this is a low-risk change.

tra accepted this revision.Feb 26 2018, 1:39 PM

Thanks. It's hard to say who really groks utils/TableGen/FixedLenCodeEmitter.cpp, adding some folks (+ @arsenm) who at least wrote the bits near my changes.

I've verified that this change doesn't change the generated code in any of the backends in trunk at all.

Great. At least we're not breaking correct code.

The basic pattern is simple: use cast<DefInit>(TI)->getDef() instead of cast<RecordRecTy>(TI->getType())->getRecord(). If TI is a DefInit, those will yield the same result. If TI is not a DefInit, then the former will crash and the latter will return the record representing some uninstantiated class, which is not meaningful.

If you can think of a way for user input to trigger this scenario, we should probably issue an error. I'm not sure if that's the case, though.
My attempts to trigger the problem were thwarted by tablegen -- it aborted with an error before TI with a wrong type could get to populateInstruction().

So I'd say this is a low-risk change.

Agreed.
If nobody chimes in today, I'm OK with landing this change.

This revision is now accepted and ready to land.Feb 26 2018, 1:39 PM
nhaehnle closed this revision.Mar 6 2018, 2:42 AM

r326699