similar to: IRMover asserts "mapping to a source type" when repeatedly linking - usage or LLVM bug?

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

Suppose that I have the following list of lists of frames 'root' (let's call it a 'tree' of frames). I want to flatten it to be a list of frames. However, if I unlist(root), it will flatten the frames as well. Is there a simply way to flatten the tree to certain depth? aframe1=data.frame(x=1:3,y=1:3) aframe2=data.frame(u=7:9,v=11:13) aframe3=data.frame(p=3:5,q=6:8)

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2.

Hi Umesh, Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions. I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in

Hi, I used the following commands on the program attached below: llvm-gcc --emit-llvm main.c -c -o main.bc opt -ipconstprop main.bc -o main1.bc diff main.bc main1.bc no difference was o/p :( The Program Segment is as shown below: #include <stdio.h> void f1(int a) { a=a+1; printf("%d",a); } void f2() { int b; b=1; f1(b); } int main() { int

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) module. During LTO, an IRMover

> It's the linkers job to hook together functions and definitions that end up in the same binary. Your OS will then hook in functions from other binaries when your executable is loaded into memory. How does it know whether it is a system function or a user-defined function? It seems that user functions have higher priorities over system functions as demonstrated by the following example.

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

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

[moved from -dev, as the thread is better suited for -users] At 5:10 PM -0600 1/30/04, James Sharp wrote: > > I've pretty much got the routing covered at this point, I'm just not sure >> how to get the Asterisk system to answer and give me dialtone immediately. >> Any ideas or recommendations would be greatly appreciated. > >app_disa will give answer and give

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,

Sorry to resurrect an old thread, but I finally got around to testing this approach (round tripping through bitcode in memory) and it works beautifully - and isn't that much slower than cloning. I have noticed however that the copy process isn't thread-safe. The problem is that in Function, there is lazy initialization code for arguments: void CheckLazyArguments() const { if

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

I have a Module/LLVMContext that I'd like to clone and manipulate in different threads (each thread may perform different translation / optimization, so they need unique copies). Currently this process has to be locked, since each clone of the Module still refers to the same LLVMContext. Is there a way to clone both the Module and LLVMContext so that the copies can be manipulated

You could probably round trip it through bitcode in memory. I think all of the IR cloning functionality assumes that only one context is being used. Even if the serialization isn't efficient as a clone could be, it should give you very high confidence that everything Just Works. :) On Tue, Jun 18, 2013 at 1:16 PM, Andrew Clinton <andrew at sidefx.com> wrote: > I have a

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 Philip, The error happens when the program finishes and it automatically calls the destructors, so it is not an error specifically inside my program. Here's the full code: #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/MCJIT.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/TargetSelect.h" #include

> On May 17, 2016, at 11:21 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > > Steven, > > As mehdi stated , the optimisation level is specific to linker and it > enables Inter-Pro opts passes ,please refer function To be very clear: the -O option may trigger *linker* optimizations as well, independently of LTO. -- Mehdi > >