search for: irmov

Hello, While trying ThinLTO, I ran into an assertion failure in IRMover: https://llvm.org/bugs/show_bug.cgi?id=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) mo...

...well! -- Taewook From: <mehdi.amini at apple.com> on behalf of Mehdi Amini <mehdi.amini at apple.com> Date: Friday, July 22, 2016 at 2:16 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180) On Jul 22, 2016, at 1:50 PM, Taewook Oh via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello, While trying ThinLTO, I ran into an assertion failure in IRMover: https://llvm.org/bugs/show_bug...

...e constants) twice and then inlining a number of Modules > > It's not exactly clear to me what you mean by "inlining a module". > Are you linking one module into another, and then inlining those > functions? Or just linking? Sorry for the imprecision. Yes, I'm using IRMover to link subsets of a module into another one. The inlining is then done by the normal inlining passes (that works). > > (selectively, but that seems unrelated), works the first time, but > > crashes the second with the "mapping to a source type" assertion. > > >...

> On Mar 23, 2018, at 16:11, Andres Freund via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > (sorry if the CC's are inappropriate, they seemed relevant based on a > git log of IRMover.cpp) > > I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One > part of that is doing inlining of operators. For that I'm using bitcode > pre-generated using clang. > > The current code uses a single LLVMContext & Orc to generate the > code....

Hi, (sorry if the CC's are inappropriate, they seemed relevant based on a git log of IRMover.cpp) I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One part of that is doing inlining of operators. For that I'm using bitcode pre-generated using clang. The current code uses a single LLVMContext & Orc to generate the code. That largely workes well. But inli...

...n inlining a number of Modules >> >> It's not exactly clear to me what you mean by "inlining a module". >> Are you linking one module into another, and then inlining those >> functions? Or just linking? > > Sorry for the imprecision. Yes, I'm using IRMover to link subsets of a > module into another one. The inlining is then done by the normal > inlining passes (that works). > > >>> (selectively, but that seems unrelated), works the first time, but >>> crashes the second with the "mapping to a source type"...

On Fri, Jul 22, 2016 at 2:44 PM, Davide Italiano <davide at freebsd.org> wrote: > On Fri, Jul 22, 2016 at 2:34 PM, Taewook Oh via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Yes, I have the repro, though I can’t publish it externally. It would be >> great if you can upstream the patch so I can try it. Thank you for your >> explanation as well! > >

...at, >> chances are that an upstream fix will be committed shortly after. >> > > Just to clarify, I'm talking about the issue in PR28180. I can't > comment about the ThinLTO one, sorry. If lld is setting enableDebugTypeODRUniquing(); on the context and isn’t using the IRMover to target an empty module, it can be the same bug. I mentioned that it should touch only ThinLTO but I had ld64 in mind. — Mehdi

With 3.9, llvm-link tells me 'invalid subroutine type ref' when linking the two code pieces below, and I don't quite understand why. It looks like it merges the debug information with the custom metadata. I've filed a ticket already [1] but as I'm not sure if this is indeed a bug or if I'm misunderstanding something, I thought I'd ask here. Any ideas? Thanks, Robin

...balVariable("llvm.global_ctors"); > addIntrinsicGlobalVariable("llvm.global_dtors"); > } > > // ... > > } > >Questions: > > 1. Is attempting to use llvm::Linker appropriate for our usage > pattern ? Should we directly use llvm::IRMover instead ? > > 2. Or, is our patch to ModuleLinker::run() the way to go ? Should > we submit back a patch along these lines ? > > 3. Other suggestions ? > >[Note] We are currently using LLVM 4.0.1-rc2. > >Cheers, >Benoit > > > >Benoit Belley >S...

...king for advise >Hi Benoit, > >It seems to me that LinkOnlyNeeded failing to link the llvm.* special >variables is a bug. I think we should probably just change the behaviour >of LinkOnlyNeeded so that it links them. > >Note that ThinLTO does not use the Linker class, it uses IRMover >directly. That might not be appropriate for your use case, though, >because IRMover does not follow references when linking (for example, if >your module defines two functions f and g, where > f calls g, it will not link g if you only ask for f). > >Peter > > >On Tue,...

...a possible solution we can use AutoUpgrade to handle the situation when the name of the intrinsic doesn't match with its signature. In such cases we have to rename the intrinsic. Then during linking if we map some isomorphic types we have to update intrinsics names. To do that we have to teach IRMover to update intrinsics signatures according to the types mapping. Does this sound reasonable? Are there any other alternatives? Artur To reproduce: $ clang -O3 -S -march=core-avx2 -emit-llvm bar.c $ clang -O3 -S -march=core-avx2 -emit-llvm foo.c $ llvm-as bar.ll $ llvm-as foo.ll $ llvm-lto foo.b...

....compiler.used"); addIntrinsicGlobalVariable("llvm.global_ctors"); addIntrinsicGlobalVariable("llvm.global_dtors"); } // ... } Questions: 1. Is attempting to use llvm::Linker appropriate for our usage pattern ? Should we directly use llvm::IRMover instead ? 2. Or, is our patch to ModuleLinker::run() the way to go ? Should we submit back a patch along these lines ? 3. Other suggestions ? [Note] We are currently using LLVM 4.0.1-rc2. Cheers, Benoit Benoit Belley Sr Principal Developer M&E-Product Development Group MA...

> On May 4, 2017, at 4:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Alrighty, a little fuzzy on how best to implement this - Adrian, you've probably got the most context here as to how to wrangle this. > > My first attempt was in IRMover.cpp, IRLinker::linkFunctionBody - after metadata is copied over, create a new subprogram derived from Dst.getSubprogram, only changing the CU over (to the first, if any, CU on the llvm.dbg.cu <http://llvm.dbg.cu/> named metadata). > > This is insufficient because all the metadata in...

...we can use AutoUpgrade to handle the situation when > the name of the intrinsic doesn't match with its signature. In such cases we > have to rename the intrinsic. Then during linking if we map some isomorphic > types we have to update intrinsics names. To do that we have to teach > IRMover to update intrinsics signatures according to the types mapping. > > Does this sound reasonable? Are there any other alternatives? > > Given our current intrinsic naming scheme, the approach you've described > seems entirely reasonable. > > An alternate scheme would be to...

...ng definitions of the vtables defined by that translation unit and the bitset metadata for CFI and vtable opt, and the "top-level" bitcode would contain everything else. The mechanism for merging summaries would be to link the embedded summary bitcode files into a single module using the IRMover, with a mechanism very similar to regular LTO. This would move all the necessary vtables and metadata into a single module where they can be processed using the existing LowerBitSets and WholeProgramDevirt passes, which would be extended to export summary metadata. This summary metadata would be...

On Thu, May 4, 2017 at 7:22 AM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > So Dehao and I have been dealing with some of the nitty gritty details of > > debug info with ThinLTO, specifically with Fission(Split DWARF). > > > > This applies to LTO as

...quot; is a MDTuple, and MDTuple nodes are leaking to the context and survive module deletion. > 3) "void ()* @a” which is the only element in this MDTuple is a “ConstantAsMetadata”, this does not leak and will be deleted with the module. > 4) a.ll is linked into an empty module, using an IRMover. This process will involved populating a map of Metadata -> mapped Metadata. One entry will be created with this MDTuple !3. > 5) a.ll is destroyed, including the “ConstantAsMetadata”. > 6) b.ll is parsed, the “null” constant will get the same pointer as the previously deleted constant f...

...and is unaffected by dropped functions. Functions can be dropped by the optimizer in the non-LTO case as well, of course, and we'd still want to be able to diagnose ODR mismatches in those functions. In any case, I think we'd want the ODR checker to always be driven by the linker, not the IRMover. This is so that we can properly diagnose ODR mismatches between bitcode files and regular object files, and avoid needing to deal with duplicate diagnostics (say if we import the same pair of ODR-mismatching modules into two different ThinLTO backends), and avoid bad interactions with the ThinLT...

Hi all, This is Michael and very happy to share my question here! My question is, is there a way to "extract" a function from Module A and write it into another Module B, and generate two new IR files? IRBuilder seems like a workable way but I have to create instructions one by one. I am new to LLVM so don't know whether it is doable, here is my experimental code: