r345109 - Debug Info (-gmodules): emit full types for non-anchored template specializations

David Blaikie via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 29 14:12:26 PDT 2018


Fair enough - pity we couldn't readily have a single implementation or at
least semantics for modular debug info between implicit and explicit modes
(I mean, my fault in part for building a separate/new system when I did
modular codegen anyway) but hopefully we'll move to explicit modules across
the board in the future anyway & standardize there.

Thanks for the context!

On Mon, Oct 29, 2018 at 12:32 PM Adrian Prantl <aprantl at apple.com> wrote:

>
>
> > On Oct 29, 2018, at 11:26 AM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > Is this a workaround for now with the intent to fix this to allow such
> implicit specializations to have their debug info modularized? I believe
> this does work correctly in modular debug info with expliict modules, would
> probably be sort of nice to have these things be consistent/similar?
>
> It started as a workaround, but I reached the conclusion that it's not
> worthwhile pursuing a more space-efficient solution. Note that all this
> patch does is emit plain old non-modular debug info for non-explicit
> template specializations, so it is definitely safe & conservative. This
> increases the size of the clang module cache in a build of clang by 4MiB
> out of 1GiB total.
>
> As you can read in my thread with Richard, it isn't possible in Clang to
> determine the clang module that contains the complete definition of a
> template specialization inside of a namespace for indirectly imported
> modules (such as in my testcase). That means that a consumer would have to
> look in every Clang module for complete types; not just in the transitive
> closure of imports of the .pcm that has the forward declaration. This
> lookup is expensive and difficult to implement in LLDB, so I decided not to
> pursue this further.
>
> -- adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20181029/6c1ada9d/attachment-0001.html>


More information about the cfe-commits mailing list