similar to: ThinLTO promotion is ending up with "invalid" IR before IR-Linking

> On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hey, > > As I’m playing with Metadata lazy-loading, I added a verifier right before running the IRLinker in FunctionImport.cpp, and it does not pass (on

On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hey, > > As I’m playing with Metadata lazy-loading, I added a verifier right before > running the IRLinker in FunctionImport.cpp, and it does not pass (on > current trunk) in a few cases. One that I looked at ended up with aliases > pointing to available_externally functions for instance. >

On Fri, Dec 23, 2016 at 11:04 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> Hey, >> >> As I’m playing with Metadata lazy-loading, I added a verifier right

We had the same problem with verification when merging/linking 2 modules: a compile unit is not listed in named metadata (llvm.dbg.cu), We worked around this problem by using the DebugInfoFinder processModule function, which identifies all the compile units in the new module, by visiting all the subprogram scopes and the already available compile units. However, this succeeds verification only if

I just hit another issue: before of ODR type uniquing on bitcode loading, we can end-up with a metadata graph that include metadata from the destination module, including a DICompileUnit. Unfortunately this compile-unit is not listed in llvm.dbg.cu and this does not pass the verifier. CC a few folks more aware of debug info that I am: is there a plan to make llvm.dbg.cu disappear? — Mehdi >

Hi Anna, Can you clarify if you observed this post-linking? — Mehdi > On Dec 23, 2016, at 12:42 PM, Anna Thomas <anna at azul.com> wrote: > > We had the same problem with verification when merging/linking 2 modules: a compile unit is not listed in named metadata (llvm.dbg.cu), > > We worked around this problem by using the DebugInfoFinder processModule function, which

Encountered “assert(GS != DefinedGlobals.end())” failure while running ThinLTO. The assertion statement is in MustPreserveGV lambda function in llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp). It seems that the assertion fails because it fails to recover the "original name" of the global value. ModuleSummaryIndex::getOriginalNameBeforePromote attempts to get the

Hi Taewook, On Thu, Jul 28, 2016 at 4:38 PM, Taewook Oh via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Encountered “assert(GS != DefinedGlobals.end())” failure while running > ThinLTO. The assertion statement is in MustPreserveGV lambda function in > llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp). > > > > It seems that the assertion fails

On Thu, Jul 28, 2016 at 5:18 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Thank you for your reply. I’m trying to create a small repro but find it > hard to nail down because originally it is a big build. This happens with > gold linker. > I think I need to see a smaller test case, looking through the code I'm not sure how we ended up in this

Hello Teresa, Thank you for your analysis. One thing to note is that the global materializer materializes the value as a function declaration, not a function definition. As I pasted on my first email, ; Materializable ; Function Attrs: nounwind uwtable define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {} is materialized to ;

On Fri, Jul 29, 2016 at 2:25 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Thank you for your analysis. One thing to note is that the global > materializer materializes the value as a function declaration, not a > function definition. As I pasted on my first email, > > > > ; Materializable > > ; Function Attrs: nounwind uwtable >

Hello Teresa, Thank you for your reply. I’m trying to create a small repro but find it hard to nail down because originally it is a big build. This happens with gold linker. Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Thursday, July 28, 2016 at 5:08 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev]

It was r274523. I’m not sure it was the same module. By mistake I restarted the build with the previous version without backing backing up the build artifacts :( Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Friday, July 29, 2016 at 3:30 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [ThinLTO]

On Fri, Jul 29, 2016 at 3:40 PM, Taewook Oh <twoh at fb.com> wrote: > It was r274523. I’m not sure it was the same module. By mistake I > restarted the build with the previous version without backing backing up > the build artifacts :( > So a couple things were added to gold since then, index-based linkonce/weak resolution and some more aggressive internalization. I don't

Yes, if I drop the debug flag then the original problem (assertion failure) comes back. Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Friday, July 29, 2016 at 3:52 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp On Fri, Jul

Ok, good to know. Any luck on a smaller test case for either of the problems? I tried building all the C/C++ SPEC cpu2006 benchmarks with -g -flto=thin at head and didn't get the failure. Let me try to look into how the debug metadata is normally dropped from the imported decl. In the meantime, could you find out the answers to the questions I had (see below) about the linkage type of the

Hi Taewook, I had a better fix for this approved (D23015), but when I went to merge this with the new LTO API I committed for pcc last week I discovered that his new API already has the same effect. I will update the bug with this info as well. Can you confirm that with a compiler built after 278338 that this problem no longer occurs? Also, any luck on a smaller test case for the -g issue? Now

No problem! I want to make sure you aren't blocked on trying ThinLTO. Thanks, Teresa On Mon, Aug 15, 2016 at 2:50 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Sorry I was working on another LLVM issue that more urgent for us, so > didn’t have much time to work on smaller test case. I’ll try the new API > and see if the issus is gone. Thanks! >

A couple weeks ago I sat down with David Blaikie to figure out what we could trim when importing debug metadata during function importing. I have a prototype that reduces the resulting .o sizes significantly with ThinLTO -g. However, I ran into some issues when cleaning up part of this in preparation for a patch. Since Mehdi indicated that he and Adrian were going to be looking at this as well

On Wed, Dec 7, 2016 at 10:36 AM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Dec-07, at 10:14, Teresa Johnson <tejohnson at google.com> wrote: > > > > A couple weeks ago I sat down with David Blaikie to figure out what we > could trim when importing debug metadata during function importing. I have > a prototype that reduces the