[PATCH] D27775: [ThinLTO] Import composite types as declarations

[David Blaikie via llvm-commits]

On Thu, Dec 15, 2016 at 9:58 AM Teresa Johnson <tejohnson at google.com> wrote:

> On Thu, Dec 15, 2016 at 9:15 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> I suppose this (applying this 'demote to declaration' optimization
> universally) can be seen as consistent with -fstandalone-debug without
> needing to be predicated by a flag. -fstandalone-debug tells you something
> about how the rest of the program you can't see. When you can see it
> (ThinLTO) you /know/ the type is available, you're not just assuming.
>
> This will be harder to justify/figure out when we eventually move to the
> next step of treating types the same way we do inline functions (in the
> summary, specify one module that retains the type definition - all other
> modules can demote their definitions of that type to a declaration). That's
> consistent with the philosophy of -fstandalone-debug (because now you
> /know/ the type is elsewhere) but will break LLDB.
>
>
> I'm not sure how it is different in practice though than what this patch
> does for the importing case - in the case where there is information in the
> index that allows you to demote the other copies to decls, you also /know/
> the type is available and aren't assuming - the index tells you that it is
> in another bitcode module that is being linked in.
>

Just chatted offline, but to summarize (& I think you summarized it better
than I was):

The specific LLDB problem only arises when you could import a definition of
a type that depends on a non-imported (declaration-only) of another type
(specifically in an inheritance relationship, but could come up in others
I'm sure). If we only import everything from another module as declarations
this doesn't arise. But if we started not importing some things, but
importing others (from the current module itself) we could create these
kinds of situations LLDB can't handle.

(but, all that aside - a story/problem for another time, as Aprantl pointed
out - this doesn't come up here, but will in the future)

- Dave


>
>
> On Thu, Dec 15, 2016 at 9:05 AM Adrian Prantl via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
> aprantl added a comment.
>
> Mehdi and I just ran a couple of experiments. LLDB can find
> forward-declared composite types that are defined in another .o file just
> fine; the only caveat is that LLDB has to potentially load the accelerator
> table of each .o file from disk in order to find the .o file with the
> definition in it. Judging from this, I think that this approach is fine.
>
>
> https://reviews.llvm.org/D27775
>
>
>
>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413 <(408)%20460-2413>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161215/73b8dced/attachment.html>