phyBrackets 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?
@Michael137 I checked GCC's implementation, it doesn't appear to have a size cap. `tree_add_const_value_attribute` calls `native_encode_initializer` which serializes the full array regardless of size. However, GCC also tends to only emit debug info for static members when they're ODR-used and get storage, so it doesn't hit the `-fstandalone-debug` duplication problem the same way. Given that's a Clang-specific concern, I'm still happy to add a size cap if we think it's warranted. Or any other idea or path we need to look for? https://github.com/llvm/llvm-project/pull/182442 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
