search for: functionimporter

...same destination (or composite) module. During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, with a call chain of thinLTOBackendTask -->CodeGen::runAll (tools/gold/gold-plugin.cpp) --> CodeGen::runLTOPasses ((tools/gold/gold-plugin.cpp) --> FunctionImpor...

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

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

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

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 >

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]

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! >

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

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

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

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]

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 ;

...TO] Only compute imports for current module in FunctionImport pass) triggered a discussion (mostly over IRC) on how best to determine import/export decisions in distributed back end compiles. Import and export decisions are made by traversing the combined index. The actual importing happens in the FunctionImporter class, which is passed the set of values to import. The importer class is either invoked directly on each backend compile, which happens in the threads launched in the libLTO path, or via the FunctionImportPass. The pass is currently used by the opt tool, by the gold-plugin when it launches ThinLT...

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

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at

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 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

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

...stination module not empty. — Mehdi During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, with a call chain of thinLTOBackendTask -->CodeGen::runAll (tools/gold/gold-plugin.cpp) --> CodeGen::runLTOPasses ((tools/gold/gold-plugin.cpp)--> FunctionImport...