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

Mon Feb 22 23:21:10 PST 2016

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160222/6aac3710/attachment.html>