Page MenuHomePhabricator

move "basic" builtins to TableGen
Needs ReviewPublic

Authored by froydnj on Jun 23 2020, 8:30 AM.



This is the first step towards a move of all builtin function
definitions living in TableGen. The intent is that once that is
accomplished, the storage cost and runtime cost (due to relocations) of
builtin function info structures can be significantly reduced by using
integer offsets into TableGen'd string tables rather than pointers.

The TableGen definitions live in a separate file to make future
conversions of the architecture-specific builtins more straightforward.

No functional change intended.

Diff Detail

Event Timeline

froydnj created this revision.Jun 23 2020, 8:30 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript

Every Record has an ID that is assigned in order. You can just sort the Records based on that in your emitter

craig.topper added inline comments.Jun 29 2020, 12:45 AM
1777 ↗(On Diff #272738)

Here’s the sort predicate for it.

froydnj updated this revision to Diff 274526.Jun 30 2020, 9:54 AM
froydnj edited the summary of this revision. (Show Details)
froydnj removed a reviewer: stoklund.

Thanks for the pointer @craig.topper ! I've updated the patch to use LessRecordByID. I've also made some small changes to how the code selects the correct macro to output and done a better job converting the builtins by using an automated script, available at . I did have to touch up the comments a bit, but the more-automated conversion pointed out several errors that my attempt to use the preprocessor had run into.

Removing Jakob since there are no more TableGen changes needed.

froydnj marked an inline comment as done.Jun 30 2020, 9:55 AM

FWIW, an in-progress tree for the proposed move for all the architecture-specific builtins is:

I don't know if the ARM/NEON/SVE builtins will be easily movable. It looks like they are separately generated from existing .td files; while you could generate .td files containing all the appropriate Builtin etc. definitions, you cannot have tablegen input depend on tablegen'd output in the general case due to:

in the non-Ninja case. If you try, you get circular dependencies. One could maybe hack around this by giving certain files different suffixes, but that feels gross.

I'm not sure how to address that issue.