[PATCH] D27775: [ThinLTO] Import composite types as declarations
Teresa Johnson via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 15 09:58:13 PST 2016
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161215/c940a97d/attachment.html>
More information about the llvm-commits
mailing list