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 <apra...@apple.com> wrote:

>
>
> > On Oct 29, 2018, at 11:26 AM, David Blaikie <dblai...@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
>
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to