[Mesa-dev] [PATCH 05/12] gallivm: Use LLVM global context.

[Jose Fonseca]

Hi Mathias,

Sorry for the delay.

----- Original Message -----
> 
> Hi Jose,
> 
> I tried to get my local llvm install again to a point where I can see
> backtrace information, but still failed to get valgrind/massif to print
> these nice backtraces. All of the llvm addresses are not resolved so far.
> 
> But a appart from that which gl example/test program do you run to see
> that leakage?

This was with some internal code (it was not even GL.)  But I've distilled the test case to its core essence.  It is in this git repos

  git clone git://people.freedesktop.org/~jrfonseca/llvm-jitstress

It's really simple to use.  If you follow the instructions there you'll be able easily to repro the problem and see precisely the same stack traces.

There's still some tweaks I want to do, but I hope to get this upstreamed into LLVM eventually.

> 
> And additionally looking at this below backtrace snippet and analyzing
> the code that is called in llvm:
> 
> On Wednesday, May 14, 2014 02:45:26 you wrote:
> > The problem is that when I do this, memory starts leaking for every
> > compilation (even with LLVM 3.4):
> > 
> >   -> 100.00% (672B): operator new(unsigned long)
> >     -> 100.00% (672B): std::_Rb_tree<llvm::EVT, llvm::EVT,
> >     std::_Identity<llvm::EVT>, llvm::EVT::compareRawBits,
> >     std::allocator<llvm::EVT> >::_M_insert_unique(llvm::EVT const&)
> >       -> 100.00% (672B): llvm::SDNode::getValueTypeList(llvm::EVT)
> >         -> 100.00% (672B): llvm::SelectionDAG::getVTList(llvm::EVT)
> 
> Ok, I see, this std::set in ./lib/CodeGen/SelectionDAG/SelectionDAG.cpp
> holds EVT instances which have a possible pointer to
> llvm::Type objects declared in llvm/IR/Type.h. And such a Type seems to
> reference
> a LLVMContext with the 'Context' member in llvm::Type.
> Since the std::set<EVT, ...>'s less operator treats EVT's to equivalent EVT's
> referencing llvm::Types originating from different LLVMContext instances
> differently,
> this grows with the LLVMContext instances around.
> 
> Ok, a correct solution inside llvm would be to prune these set entries once
> the
> LLVMContext dies.
> 
> A workaround from our side could probably be to have a LLVMContext private to
> the
> GL context as already suggested. That would still grow with the number of GL
> contexts.

Yes, I think that's a great idea.

In short, besides the existing gallivm_context (which is actually not per context, but rather per module/ compilation unit) there should be a new object, that's truly per context, that holds two things:

 - LLVMContextRef
 - src/gallium/auxiliary/gallivm/lp_bld_misc.cpp's ShaderMemoryManager.

Each draw_context and llvmpipe_context should one of these (it's fine not to share the same.

The existing gallivm_context should probably be renamed gallivm_module.


Jose