search for: irmovers

...ile 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) 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 “TheLinke...

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

Hi, On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: > > The second approach is to *not* cache modules but re-read them from disk > > (or memory, but that's irrelevant here). That works without any sort of > > asserts, but "leaks" memory because everytime a module is re-read from > > disk it re-creates types (cf

> 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

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 inlining

> On Mar 26, 2018, at 17:09, Andres Freund <andres at anarazel.de> wrote: > > Hi, > > On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: >>> The second approach is to *not* cache modules but re-read them from disk >>> (or memory, but that's irrelevant here). That works without any sort of >>> asserts, but "leaks" memory

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

It seems that the patch works for me as well, though the linker crashes with another error after that. Thanks! Mehdi, I couldn’t quite understand what do you mean by you don’t have a repro so you couldn’t upstream the patch. Aren’t .ll files you attached sufficient to submit along with the patch? If there is anything I can help you to upstream it, please let me know. -- Taewook On 7/22/16,

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

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

In the current mangling scheme for overloaded intrinsics we include overloaded type names in the intrinsic name. For example: %struct.foobar = type { i32 } declare <4 x %struct.foobar*> @llvm.masked.load.v4p0struct.foobar(<4 x %struct.foobar*>*, i32, <4 x i1>, <4 x %struct.foobar*>) Verifier checks that an overloaded intrinsic name matches with its signature. When

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

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

On 18 April 2016 at 19:22, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 04/18/2016 09:45 AM, Artur Pilipenko via llvm-dev wrote: > > In the current mangling scheme for overloaded intrinsics we include > overloaded type names in the intrinsic name. For example: > > %struct.foobar = type { i32 } > declare <4 x %struct.foobar*>

Hi all, I wanted to make this proposal to extend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and whole-program devirtualization optimizations under ThinLTO. Overview The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example,

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

> On 2016-Jul-26, at 02:22, Mehdi Amini <mehdi.amini at apple.com> wrote: > > +CC Duncan``` > >> On Jul 25, 2016, at 8:53 PM, Robin Sommer via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> With 3.9, llvm-link tells me 'invalid subroutine type ref' when >> linking the two code pieces below, and I don't quite understand

On Sat, Jun 10, 2017 at 11:00 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-06-07 16:32 GMT-07:00 Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org>: > >> On Wed, Jun 7, 2017 at 8:18 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> Does this need LLVM support - or is there some generic representation

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: