This is an archive of the discontinued LLVM Phabricator instance.

Add enums as global variables in the IR metadata.
ClosedPublic

Authored by akhuang on May 29 2019, 4:43 PM.

Details

Summary

Keeps track of the enums that were used by saving them as DIGlobalVariables,
since CodeView emits debug info for global constants.

Diff Detail

Repository
rL LLVM

Event Timeline

akhuang created this revision.May 29 2019, 4:43 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 29 2019, 4:43 PM
rnk accepted this revision.May 30 2019, 2:01 PM

lgtm That was... easier and more painless than I would've imagined.

This revision is now accepted and ready to land.May 30 2019, 2:01 PM
This revision was automatically updated to reflect the committed changes.

Is it practical/possible to do this in LLVM rather than in Clang? I'd have thought it'd be best to keep the IR metadata as output-format agnostic as practical/possible to reduce divergent codepaths, etc?

I think the main issue was keeping track of which enums are used?

I think the main issue was keeping track of which enums are used?

The used enums would still end up in the 'enums' list for the DICompileUnit, right? (If CodeView needs more enums in the list than DWARF does - yeah, that's probably a necessary frontend change - to put the extra needed enums in the enums list)

They should all be there, but emitting the unused enums makes the binary sizes larger. (I think around 6% increase? I forget the size difference for only emitting used enums)

rnk added a comment.Jun 18 2019, 5:54 AM

We did things this way to track which enumerators were used, not which enums were used. Size data showed it was worth doing (6%). The existing format doesn't support tracking usage of individual enumerators, so we pretended they were const integers to avoid changing the schema.

In D62635#1548157, @rnk wrote:

We did things this way to track which enumerators were used, not which enums were used. Size data showed it was worth doing (6%). The existing format doesn't support tracking usage of individual enumerators, so we pretended they were const integers to avoid changing the schema.

Ah - describing all the enumerators in any emitted enum would be too many bits/too much size in output?

rnk added a comment.Jun 18 2019, 10:04 AM
In D62635#1548157, @rnk wrote:

We did things this way to track which enumerators were used, not which enums were used. Size data showed it was worth doing (6%). The existing format doesn't support tracking usage of individual enumerators, so we pretended they were const integers to avoid changing the schema.

Ah - describing all the enumerators in any emitted enum would be too many bits/too much size in output?

Yes, that's what @akhuang tried and measured against to come up with the 6% number.

In D62635#1548721, @rnk wrote:
In D62635#1548157, @rnk wrote:

We did things this way to track which enumerators were used, not which enums were used. Size data showed it was worth doing (6%). The existing format doesn't support tracking usage of individual enumerators, so we pretended they were const integers to avoid changing the schema.

Ah - describing all the enumerators in any emitted enum would be too many bits/too much size in output?

Yes, that's what @akhuang tried and measured against to come up with the 6% number.

Ah, OK - unused enumerators in used enumerations, rather than all unused enumerators in all enumerations unused or used... I'm with you now. Thanks!