[PATCH] D16440: [ThinLTO] Link in only necessary DICompileUnit operands

[David Blaikie via llvm-commits]

On Fri, Jan 29, 2016 at 10:48 AM, Teresa Johnson <tejohnson at google.com>
wrote:

>
>
> On Fri, Jan 29, 2016 at 8:33 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> On Fri, Jan 29, 2016 at 5:47 AM, Teresa Johnson via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>>> tejohnson added a comment.
>>>
>>> > > I think so. At least for composite types. Are there any cases, other
>>> than from the retainedTypes list on the compile unit, where a
>>> DICompositeType node is referenced by its address rather than by UUID?
>>>
>>> >
>>>
>>> >
>>>
>>> > Try types without a mangled name - I suppose one example might be
>>> something like:
>>>
>>> >
>>>
>>> > a.cpp:
>>>
>>> >  void b();
>>>
>>> >  int main() {
>>>
>>> >
>>>
>>> >   b();
>>>
>>> >
>>>
>>> > }
>>>
>>> >
>>>
>>> > b.cpp:
>>>
>>> >  namespace {
>>>
>>> >  struct anon {
>>>
>>> >  };
>>>
>>> >  void bimpl(anon) {
>>>
>>> >  }
>>>
>>> >  }
>>>
>>> >  void b() {
>>>
>>> >
>>>
>>> >   bimpl(anon());
>>>
>>> >
>>>
>>> > }
>>>
>>> >
>>>
>>> > If bimpl is imported into a (presumably after b is imported into a)
>>> then you'll see a type without a mangled name... what you should do with
>>> this is perhaps a difficult question. A debugger's going to have a hard
>>> time identifying these types (or even the two 'bimpl' functions) as the
>>> same when they're in two different object files & flagged as being "local"
>>> entities...
>>>
>>>
>>> Confirmed that in this case, the composite type for anon is in the
>>> subroutine type list for bimpl, and that when we import bimpl into a.cpp we
>>> therefore import the full composite type definition.
>>>
>>> It isn't clear to me from your last sentence what we should do here.
>>> Does having the full type definition imported make it easier or harder for
>>> the debugger?
>>>
>>
>> (probably as Duncan said, there's nothing else we can really do here
>> other than to have the full type definition imported)
>>
>
> Ok, thanks, that's what happening with this patch so that's good.
>
>
>>
>> As for what debuggers will do with this - I'm not really sure. I think
>> it'll hurt users a little bit, but don't know of any way to improve that
>> off hand.
>>
>> (what I'm thinking might happen is that, when the user is evaluating
>> expressions within the context of the Compilation Unit that imported a
>> local function (or non-local function using a local type, not sure how we
>> emit that, maybe it still looks like a local function) from another CU,
>> it'll find the imported local, probably discover that it has no definition
>> (because it was only imported for inlining, etc - the definition would
>> never be emitted here), and be unable to call it in the expression
>> evaluator because it wouldn't know that the local function in another CU is
>> the same function)
>>
>> Not sure whether local types would present the same/similar issues - they
>> could introduce strange name lookup situations for example:
>>
>> a.cpp:
>> namespace a {
>> namespace {
>> struct foo { int a; };
>> }
>> }
>> void f1() {
>>   a::foo f;
>> }
>>
>> b.cpp:
>> namespace {
>> struct foo { float b; };
>> }
>> namespace a {
>> void f2() {
>>   f1();
>>   foo f;
>> }
>> }
>>
>> f1 is imported into the b.cpp module, along with the types necessary to
>> describe it.
>>
>> So now b.cpp's debug info looks like this:
>> namespace {
>> struct foo { float b; };
>> }
>> // f1
>> namespace a {
>> struct foo { int a; };
>> void f2() {
>>   f1();
>>   foo f; // but miraculously, this 'foo' refers to ::foo, not a::foo
>> }
>> }
>>
>> Now if the user is in the expression evaluator in f2 and refers to 'foo',
>> the debugger will find a::foo, even though the user is staring at code that
>> uses the unqualified 'foo' to refer to ::foo
>>
>
> What happens in an LTO build in this case? Will it be similarly confused?
> If not, how does it handle this case since all the types are being merged?
>

In a full LTO, I /think/ what we do at the moment is cross-CU references
(or at least I remember that being done on MacOS by Adrian/Duncan/etc - but
I think it happens generally/cross-platform). So the anonymous type remains
in one CU in the DWARF, and the function in another CU can refer to it...
(not sure if we do that for the inlined functions themselves - have the
inline instance refer, cross-CU to the abstract instance in the right CU, I
don't think so)

Not sure what debuggers do with that, but it's somewhat more informative
and they /could/ do the right thing.

- Dave


>
> Thanks,
> Teresa
>
>
>> I don't expect this sort of thing to be terribly common - but it's seems
>> technically possible to produce awkward debugging situations when importing
>> file-local entities. ("benign" violations of the ODR may cause other
>> problems, but our type uniquing by mangled name will probably already break
>> those in LTO at least, FWIW)
>>
>>
>>>
>>> Thanks,
>>> Teresa
>>>
>>> >
>>>
>>> >
>>>
>>> > - Dave
>>>
>>>
>>>
>>> http://reviews.llvm.org/D16440
>>>
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>
>>
>
>
> --
> 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/20160129/45893877/attachment.html>