dblaikie added a comment.
In D106084#2897515 <https://reviews.llvm.org/D106084#2897515>, @jmorse wrote:
> David wrote:
>
>> think what I'm missing here: If -fno-standalone-debug is already in use/the
>> default and is causing missing types because parts of the program are bulit
>> without debug info, then I'm not sure what the rationale is for slicing
>> -fstandalone-debug into a "has ctor homing" and a "doesn't have ctor homing"
>> strategy. The same general design philosophy applies - that in both cases
>> (about 4 cases in total now: types that aren't required to be complete,
>> explicitly instantiated templates, vtables, and now ctor homing) the whole
>> program must be compiled with debug info enabled for these DWARF size
>> optimizations to be sound.
>
> It's a matter of degree:
>
> - Some types go missing, but due to the dllimport mechanism mentioned, all
> the important ones are retained,
> - Switching to -fstandalone-debug increases the amount of DWARF by ~50% in
> experiments I've run, which for a {single-file-recompile, link,
> load-into-debugger} round trip will translate to an almost 50% increase in
> round-trip-time. (What with DWARF being the major part of linking and
> debugger-loading).
>
> Thus the status quo (-fno-standalone-debug and closed-source libraries)
> hasn't been conceptually sounds, but it's given a "good enough" debugging
> experience without major round-trip-time penalty.
I think it'd be unfortunate to split this hair in LLVM/Clang proper & feel like
that sort of value tradeoff might be better suited in a downstream patch.
(mostly because eventually it'd be good to get rid of the distinction between
other type homing and ctor type homing entirely - there's already 3 categories
of type homing under the existing category (type completeness, explicit
template instantiations, and vtable based homing) & I don't think there's a
good line to draw between those and ctor type homing - and module type homing
(which I think I've already implemented &the is under -fno-standalone-debug,
but no one's using modular code generation right now so it's not super
interesting to anyone), maybe ThinLTO type homing (which would be a bit more
robust than the others, since it has whole program-ish view)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106084/new/
https://reviews.llvm.org/D106084
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
