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

Tue Feb 23 09:22:19 PST 2016

On Tue, Feb 23, 2016 at 9:12 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

> I think in the error output I sent, I noticed the issue seemed to happen
> on DIDerivedType metadata that have a "baseType".
>

That's not really different than the below example, where the types were
also reached via a DIDerivedType baseType. If we mapped in the
DIDerivedType we should have mapped in the reached type identifier.

> --
> Mehdi
>
> On 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.
>
> 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/19a2314b/attachment.html>