Michael137 wrote: > > > > Getting an idea of size increase would be useful. (_Possibly_ limiting > > > > it to types where it would otherwise be impossible to get to by > > > > debuggers (e.g., integrals/floats)) > > > > > > > > > > > > @Michael137 Thanks for the idea, I ran some size comparison, on a > > > synthetic file with 4 constexpr array static members (char[6], int[10], > > > unsigned char[3], short[4]), `debug_info` grows by 61 bytes, basically > > > just the raw array content plus a few bytes of block-length encoding. On > > > an actual LLVM source file (CommandLine.cpp), the diff is literally zero, > > > no constexpr array static members, no cost. > > > > ``` > > > > Synthetic (4 constexpr arrays): > > > > +23% +61 .debug_info > > > > +1.2% +2 .debug_abbrev > > > > > > > > Real file (llvm/lib/Support/CommandLine.cpp): > > > > [ = ] 0 TOTAL > > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the cost is purely pay-for-what-you-use, just the raw byted of > > > whatever arrays exist, and in practice I think most TU's won't have any > > > constexpr array static members, so the impact across a real build should > > > be negligible. > > > > And limiting to types where debuggers can't otherwise recover the value, > > > that make sense. Let me know if you'd prefer that. > > > > > > I guess the issue is there isn't/we haven't identified a codebase with > > widespread adoption of the feature to test the impact on? > > > > > > My concern would be especially having these sort of entities in headers > > (especially on Apple platforms which uses `-fstandalone-debug` by default - > > where more copies of class definition debug info are emitted into object > > files (even if they are then deduplicated in a final dsym)) - the object > > size impact could be significant if the array bytes are added to every > > definition of the enclosing type. Usually we try to only emit things that > > are ODR-used and maybe even only things that are still referenced after > > optimizations, but there certainly are tradeoffs. (eg: Sony folks take this > > further and only emit member function declarations for functions that are > > called, but the rest of us emit them all when emitting the class > > definition, whether or not the member function is used) > > > > Hi @dwblaikie , That's a good point, I hadn't considered the > `-fstandalone-debug` duplication across TUs for arrays in headers. indeed > arrays can be arbitrarily large. > > > > Would a size cap work here? E.g., only emit `DW_AT_const_value` for arrays > where the total byte size is ≤ some threshold (say 64 bytes). That could > covers the common useful cases small lookup tables, short char arrays, > without risking bloat from large arrays in widely-included headers. or if we > should prefer a different approach like gating it behind a flag?
Does GCC do size capping? https://github.com/llvm/llvm-project/pull/182442 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
