[Mesa-dev] [PATCH] radeon/llvm: Use LLVM C API for compiling LLVM IR to ISA.

[Jose Fonseca]

----- Original Message -----
> On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote:
> > ----- Original Message -----
> > > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> > > > 
> > > > Hi Tom,
> > > > 
> > > > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> > > > > First of all, thanks for investigating this.  The information you've
> > > > > provided has helped me a lot.
> > > > Good to hear that it helps.
> > > > 
> > > > > I took a shot at implementing it this way with private static copies
> > > > > of
> > > > > llvm.  I've pushed the initial work to this branch:
> > > > > git://people.freedesktop.org/~tstellar/mesa llvm-build
> > > > > 
> > > > > I was able to hide the LLVM symbols by using the --exclude-libs
> > > > > linker
> > > > > flag and so far I've tested with glxgears, an opencl example and also
> > > > > eglgears and they all work.  I still need to do some more testing,
> > > > > but
> > > > > any thoughts on what I've done so far in this branch?
> > > > 
> > > > I will look at this as soon as I find time. Probably not before the
> > > > beginning
> > > > of next week.
> > > > 
> > > 
> > > I've thought about this some more, and I think that the best solution
> > > might be to move all LLVM API calls into gallivm and build it as a
> > > shared object with it's own private copy of LLVM statically linked.  This
> > > way
> > > we
> > > would still have a private copy of LLVM to work with, but without having
> > > to statically link every single gallium target with LLVM.  Any thoughts
> > > about this?
> > 
> > I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls
> > too.  So to prevent symbol collision with apps that use them, we'd need to
> > expose all LLVM calls we need under nome unique prefix.
> >
> 
> I didn't realize this, and actually the radeon drivers use a lot of
> the LLVMBuildXxxx calls too.
>  
> > Also note that gallivm has a lot of function calls. This would also pollute
> > the app's namespace.
> > 
> > In short, for this to work we should do it not for whole gallivm, but with
> > a new module, just for LLVM C calls + the additional helpers, and use an
> > unique prefix (e.g., MesaLLVMXxxx) for everything.
> > 
> > And we should have a new header, that #defines LLVMFoo MesaLLVMFoo, so that
> > Mesa code doesn't need to be changed all over the place.
> > 
> 
> I think this is a good approach, however before we make big changes to
> Mesa I want to make sure we know what problems we are trying to solve
> with these changes.  As far as I understand it, the current problems
> are:
> 
> 1. If an application is using the LLVM API outside of Mesa, then it is
> impossible for Mesa to safely use the llvm_*_multithreaded() functions.
> 
> 2. If an application is using a different version of LLVM than Mesa,
> then it might incorrectly use the LLVM symbols that are included in
> the Mesa libraries.
> 
> Are there others?

I know a couple more:

- There are a bunch of options that need to be set via globals, (see lp_set_target_options), so app/drivers could tamper with each other options.

- llvm::cl::ParseCommandLineOptions will complain if called multiple times -- I think we no longer need to call it these days though

In short, LLVM was not designed for multiple users in the same process.

Jose