similar to: Lazily Loaded Modules and Linker::LinkOnlyNeeded

+cc Artem, who added the LinkOnlyNeeded flag. On Wed, Apr 20, 2016 at 9:18 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Neil, > > On Apr 20, 2016, at 5:20 AM, Neil Henning via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > TL;DR - when linking from a lazily loaded module and using > Linker::LinkOnlyNeeded, bodies of used functions

Hey all, For LinkModules, /*dest*/ is a fully materialized module, /*src*/ is a lazily loaded module. From what I understood, getLinkedToGlobal() is finding the function in /*src*/ that matches some function declaration in /*dest*/, and given that /*src*/ is lazily loaded it could be un-materialized. The functions I need brought in from /*src*//**/ into /*dest*/ are always declarations in

> > > I understood from his description that he reversed the destination and > source so that destination is the user code. > I assumed it was not lazy loaded, but that would explain the question then > :) > > Neil: can you clarify? If Teresa is right, why aren't you materializing > the destination module entirely? > > I don't think it has ever been tried

Hi Everyone, We are looking for advise regarding the proper use of LTO in conjunction with just-in time generated code. Our usage scenario goes as follows. 1. Our front-end generates an LLVM module. 2. A small runtime support library is linked-in. The runtime library is distributed as bitcode. It is generated using "clang++ -emit-llvm' and 'llvm-link'. This allows

Thanks for the hindsight. I am currently working on a patch/potential fix which introduces a new Linker::ImportIntrinsicGlobalVariables flag. The patch includes a unit test reproducing the problem. Hopefully, that will help getting more feedback. Note that it might take a while before I am allowed to upload the patch since I need approval from Autodesk Legal department. Cheers, Benoit Benoit

Thanks Peter, this is very useful feedback. I did manage to change the behavior of LinkOnlyNeeded to correctly import all variables with AppendingLinkage. In fact, I discovered that there was already something fishy. A variable with AppendingLinkage would get imported correctly from the source module if the destination module already contained a definition for that variable and wouldn't be

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 >

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

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

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

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]

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

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, I'm trying to port some code from the original JIT (a project I haven't had a chance to work on for quite a while) to the new Orc JIT. I thought I'd try to use the Kaleidoscope tutorial as a starting point for getting acquainted with the new JIT and so I first tried to add the ability to load an existing bitcode file, then make calls to functions from that file. That was easy to

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

Hi All, I'm working on various cleanups and simplifications to the asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These