search for: thinltobackendtask

...28180. I found that the assertion failure is happening because IRMover tries to map the metadata that already mapped in the destination module, and it seems that this happens because two different IRMovers are used for the 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 in...

...map). This happens only in ThinLTO and not in LTO because LTO starts with an empty module, so when you move the first module into the "merged module”, the map gets initialized. In ThinLTO the mover starts with the destination 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 in...

...he only way we should be creating a new local copy is if foo() already had a copy in the dest module. But when we call ThinLTO internalization we are doing so before any function importing. The gold-plugin should have linked the module being compiled in the ThinLTO backend into an empty module from thinLTOBackendTask, so we should not already have a copy of foo() in the dest module. I must be missing something...in lieu of a smaller test case, can you trace through what happens when we call linkGlobalValueProto for the local materializer, and see why we don't find the copy of SGV already materialized by th...

...he only way we should be creating a new local copy is if foo() already had a copy in the dest module. But when we call ThinLTO internalization we are doing so before any function importing. The gold-plugin should have linked the module being compiled in the ThinLTO backend into an empty module from thinLTOBackendTask, so we should not already have a copy of foo() in the dest module. I must be missing something...in lieu of a smaller test case, can you trace through what happens when we call linkGlobalValueProto for the local materializer, and see why we don't find the copy of SGV already materialized by th...

...d be creating a new local copy is if foo() > already had a copy in the dest module. But when we call ThinLTO > internalization we are doing so before any function importing. The > gold-plugin should have linked the module being compiled in the ThinLTO > backend into an empty module from thinLTOBackendTask, so we should not > already have a copy of foo() in the dest module. > > > > I must be missing something...in lieu of a smaller test case, can you > trace through what happens when we call linkGlobalValueProto for the local > materializer, and see why we don't find the copy...

...he only way we should be creating a new local copy is if foo() already had a copy in the dest module. But when we call ThinLTO internalization we are doing so before any function importing. The gold-plugin should have linked the module being compiled in the ThinLTO backend into an empty module from thinLTOBackendTask, so we should not already have a copy of foo() in the dest module. I must be missing something...in lieu of a smaller test case, can you trace through what happens when we call linkGlobalValueProto for the local materializer, and see why we don't find the copy of SGV already materialized by...

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]

...d be creating a new local copy is if foo() > already had a copy in the dest module. But when we call ThinLTO > internalization we are doing so before any function importing. The > gold-plugin should have linked the module being compiled in the ThinLTO > backend into an empty module from thinLTOBackendTask, so we should not > already have a copy of foo() in the dest module. > > > > I must be missing something...in lieu of a smaller test case, can you > trace through what happens when we call linkGlobalValueProto for the local > materializer, and see why we don't find the copy...

...he only way we should be creating a new local copy is if foo() already had a copy in the dest module. But when we call ThinLTO internalization we are doing so before any function importing. The gold-plugin should have linked the module being compiled in the ThinLTO backend into an empty module from thinLTOBackendTask, so we should not already have a copy of foo() in the dest module. I must be missing something...in lieu of a smaller test case, can you trace through what happens when we call linkGlobalValueProto for the local materializer, and see why we don't find the copy of SGV already materialized by...

...d be creating a new local copy is if foo() > already had a copy in the dest module. But when we call ThinLTO > internalization we are doing so before any function importing. The > gold-plugin should have linked the module being compiled in the ThinLTO > backend into an empty module from thinLTOBackendTask, so we should not > already have a copy of foo() in the dest module. > > > > I must be missing something...in lieu of a smaller test case, can you > trace through what happens when we call linkGlobalValueProto for the local > materializer, and see why we don't find the copy...

...s if foo() >>> already had a copy in the dest module. But when we call ThinLTO >>> internalization we are doing so before any function importing. The >>> gold-plugin should have linked the module being compiled in the ThinLTO >>> backend into an empty module from thinLTOBackendTask, so we should not >>> already have a copy of foo() in the dest module. >>> >>> >>> >>> I must be missing something...in lieu of a smaller test case, can you >>> trace through what happens when we call linkGlobalValueProto for the local >>&...

...d be creating a new local copy is if foo() > already had a copy in the dest module. But when we call ThinLTO > internalization we are doing so before any function importing. The > gold-plugin should have linked the module being compiled in the ThinLTO > backend into an empty module from thinLTOBackendTask, so we should not > already have a copy of foo() in the dest module. > > > > I must be missing something...in lieu of a smaller test case, can you > trace through what happens when we call linkGlobalValueProto for the local > materializer, and see why we don't find the copy...