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

Tue Feb 23 08:52:15 PST 2016

On Tue, Feb 23, 2016 at 8:44 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, Feb 23, 2016 at 6:59 AM, Teresa Johnson <tejohnson at google.com>
> wrote:
>
>> Both of these cases work fine. The types are in fact DICompositeType, and
>> are reached via the DISubroutineType for the imported function. E.g. for
>> your second example:
>>
>> struct foo { };
>> struct bar { };
>> void f(foo (*)(bar)) {
>> }
>>
>> The original module looks like:
>>
>> !4 = !DICompositeType(tag: DW_TAG_structure_type, name: "foo", file: !1,
>> line: 1, size: 8, align: 8, flags: DIFlagFwdDecl, identifier: "_ZTS3foo")
>> !5 = !DICompositeType(tag: DW_TAG_structure_type, name: "bar", file: !1,
>> line: 2, size: 8, align: 8, flags: DIFlagFwdDecl, identifier: "_ZTS3bar")
>> ...
>> !7 = distinct !DISubprogram(name: "f", linkageName: "_Z1fPF3foo3barE",
>> scope: !1, file: !1, line: 3, type: !8, isLocal: false, isDefinition: true,
>> scopeLine: 3, flags: DIFlagPrototyped, isOptimized: true, variables: !13)
>> !8 = !DISubroutineType(types: !9)
>> !9 = !{null, !10}
>> !10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64,
>> align: 64)
>> !11 = !DISubroutineType(types: !12)
>> !12 = !{!"_ZTS3foo", !"_ZTS3bar"}
>>
>> Because they are reached via the imported function's DISubprogram, they
>> get imported properly.
>>
>
> OK, so the code that retained these types isn't the code I was looking at
> (getCompositeTypeToImport)? Where is getCompositeTypeToImport used?
>

getCompositeTypeToImport is invoked in a couple places within
linkImportedCompileUnit. The one that likely invoked it here was the first
call there, which checks if the identifier for a retained type was mapped
into the dest module (which it would have here since it was referenced via
an imported subroutine).

>
>
>>
>> On Mon, Feb 22, 2016 at 11:21 PM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> Yeah - I figured you would've caught it already if it were this simple.
>>> What sort of testing have you done?
>>>
>>> Happy to go through a few things with you in person tomorrow as well.
>>> Perhaps I'm just not understanding the algorithm you're implementing here.
>>>
>>> On Mon, Feb 22, 2016 at 9:09 PM, Teresa Johnson <tejohnson at google.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Feb 22, 2016 at 8:03 PM, David Blaikie <dblaikie at gmail.com>
>>>> wrote:
>>>>
>>>>> Have either of you tried creating a simple test case? Naively it looks
>>>>> like any use of a pointer-to-user-defined type would hit this in some way,
>>>>> no?
>>>>>
>>>>> import this function:
>>>>>
>>>>> struct foo { };
>>>>> void bar(foo *f) {
>>>>> }
>>>>>
>>>>> and I think the code will look at the type of 'f',
>>>>> getCompositeTypeToImport will immediately return null, because 'f' isn't a
>>>>> DICompositeType, and the type won't be retained.
>>>>>
>>>>> Note that the type could be worse, it could involve importing more
>>>>> than one type:
>>>>>
>>>>> struct foo { };
>>>>> struct bar { };
>>>>> void f(foo (*)(bar)) {
>>>>> }
>>>>>
>>>>>
>>>> Hadn't tried that because I wasn't sure what to look for to be honest
>>>> (especially since my testing is all fine at this point). Will give that a
>>>> try to see how it behaves.
>>>>
>>>>
>>>>> On Mon, Feb 22, 2016 at 7:39 PM, Teresa Johnson via llvm-commits <
>>>>> llvm-commits at lists.llvm.org> wrote:
>>>>>
>>>>>> Unfortunately without seeing how the types were referenced in the
>>>>>> original module I may not be able to deduce why they weren't pulled in. But
>>>>>> go ahead and send me the IR after importing in the meantime and I will see
>>>>>> what I can figure out.
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 22, 2016 at 6:02 PM, Mehdi Amini <mehdi.amini at apple.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Unfortunately IIRC it involved 800 files, and I don't have them. I
>>>>>>> need to reproduce and it'll take some time. I can send you the IR *after*
>>>>>>> importing (the broken module) if it can help (not sure).
>>>>>>>
>>>>>>> --
>>>>>>> Mehdi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Feb 22, 2016, at 5:52 PM, Teresa Johnson <tejohnson at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Can you give me a test case to reproduce, or at least the IR for the
>>>>>>> module we're importing from (where these presumably came from) and which
>>>>>>> function(s) were imported?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Teresa
>>>>>>>
>>>>>>> On Mon, Feb 22, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We still have an issue with this patch, when compiling this with
>>>>>>>> thinlto and debug info:
>>>>>>>> https://github.com/adobe/webkit/blob/master/Source/WebCore/inspector/InspectorRuntimeAgent.cpp
>>>>>>>>
>>>>>>>> I haven't had time to narrow it unfortunately, it seems that
>>>>>>>> "baseType" for some DIDerivedType entries are not present.
>>>>>>>> What we see is a broken LLVM Module straight after the
>>>>>>>> FunctionImporter. The output looks like this:
>>>>>>>>
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC14ScopeLabelInfoE"
>>>>>>>> !121713 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType:
>>>>>>>> !"_ZTSN3JSC14ScopeLabelInfoE", size: 64, align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC15DeclarationTypeE"
>>>>>>>> !121577 = !DISubroutineType(types: !121578)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC17AssignmentContextE"
>>>>>>>> !121580 = !DISubroutineType(types: !121581)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC17DestructuringKindE"
>>>>>>>> !121577 = !DISubroutineType(types: !121578)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC21DeclarationImportTypeE"
>>>>>>>> !121606 = !DISubroutineType(types: !121607)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC23SourceProviderCacheItemE"
>>>>>>>> !121621 = !DIDerivedType(tag: DW_TAG_const_type, baseType:
>>>>>>>> !"_ZTSN3JSC23SourceProviderCacheItemE")
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE10LexerStateE"
>>>>>>>> !121743 = !DISubroutineType(types: !121744)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE15AutoPopScopeRefE"
>>>>>>>> !121600 = !DIDerivedType(tag: DW_TAG_reference_type, baseType:
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE15AutoPopScopeRefE", size: 64, align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE20ExpressionErrorClassE"
>>>>>>>> !121571 = !DISubroutineType(types: !121572)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE23AutoCleanupLexicalScopeE"
>>>>>>>> !121604 = !DIDerivedType(tag: DW_TAG_reference_type, baseType:
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE23AutoCleanupLexicalScopeE", size: 64,
>>>>>>>> align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE25ExpressionErrorClassifierE"
>>>>>>>> !121535 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType:
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE25ExpressionErrorClassifierE", size: 64,
>>>>>>>> align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerIhEEE9SavePointE"
>>>>>>>> !121751 = !DISubroutineType(types: !121752)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE10LexerStateE"
>>>>>>>> !122000 = !DISubroutineType(types: !122001)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE15AutoPopScopeRefE"
>>>>>>>> !121866 = !DIDerivedType(tag: DW_TAG_reference_type, baseType:
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE15AutoPopScopeRefE", size: 64, align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE20ExpressionErrorClassE"
>>>>>>>> !121838 = !DISubroutineType(types: !121839)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE23AutoCleanupLexicalScopeE"
>>>>>>>> !121870 = !DIDerivedType(tag: DW_TAG_reference_type, baseType:
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE23AutoCleanupLexicalScopeE", size: 64,
>>>>>>>> align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE25ExpressionErrorClassifierE"
>>>>>>>> !121803 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType:
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE25ExpressionErrorClassifierE", size: 64,
>>>>>>>> align: 64)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC6ParserINS_5LexerItEEE9SavePointE"
>>>>>>>> !122008 = !DISubroutineType(types: !122009)
>>>>>>>> unresolved type ref
>>>>>>>> !"_ZTSN3JSC9ScopeNodeE"
>>>>>>>> !121635 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType:
>>>>>>>> !"_ZTSN3JSC9ScopeNodeE", size: 64, align: 64)
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mehdi
>>>>>>>>
>>>>>>>>
>>>>>>>> > On Feb 22, 2016, at 2:20 PM, Teresa Johnson <tejohnson at google.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > tejohnson updated this revision to Diff 48732.
>>>>>>>> > tejohnson added a comment.
>>>>>>>> >
>>>>>>>> > Handle a null MD passed to MapMetadata to address problem
>>>>>>>> reported by
>>>>>>>> > ahatanak.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > http://reviews.llvm.org/D16440
>>>>>>>> >
>>>>>>>> > Files:
>>>>>>>> >  include/llvm/Linker/IRMover.h
>>>>>>>> >  lib/Linker/IRMover.cpp
>>>>>>>> >  lib/Linker/LinkModules.cpp
>>>>>>>> >  lib/Transforms/Utils/ValueMapper.cpp
>>>>>>>> >  test/Linker/thinlto_funcimport_debug.ll
>>>>>>>> >  test/Transforms/FunctionImport/Inputs/funcimport_debug.ll
>>>>>>>> >  test/Transforms/FunctionImport/funcimport_debug.ll
>>>>>>>> >
>>>>>>>> > <D16440.48732.patch>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>>>>>> 408-460-2413
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>>>>> 408-460-2413
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>
>>>
>>
>>
>> --
>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>> 408-460-2413
>>
>
>

-- 
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/20160223/f2629a5f/attachment.html>