search for: globals2

...When cloning? > - When linking the clone into another module? > If the latter, which module did you link the cloned "a" into? It fires when linking the clone. I'm trying to: 1) IRMover(main1).move(CloneModule(a), list-of-globals1) 2) IRMover(main1).move(CloneModule(b), list-of-globals2) 3) IRMover(main2).move(CloneModule(a), list-of-globals1) 4) IRMover(main2).move(CloneModule(b), list-of-globals2) The assert fires in 3). The reason is that an opaque type in a (which is the same as the type in CloneModule(a), because cloning doesn't recreate types), got linked into main1 in...

> 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

...king the clone into another module? >> If the latter, which module did you link the cloned "a" into? > > It fires when linking the clone. I'm trying to: > > 1) IRMover(main1).move(CloneModule(a), list-of-globals1) > 2) IRMover(main1).move(CloneModule(b), list-of-globals2) > 3) IRMover(main2).move(CloneModule(a), list-of-globals1) > 4) IRMover(main2).move(CloneModule(b), list-of-globals2) (Ah... now I'm following your example.) > The assert fires in 3). The reason is that an opaque type in a (which is > the same as the type in CloneModule(a), becau...

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