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

[Tom Stellard]

On Wed, May 01, 2013 at 04:11:51PM +0200, Mathias Fröhlich wrote:
> 
> Tom, Jose,
> 
> On Tuesday, April 30, 2013 16:56:56 Tom Stellard wrote:
> > I took the linker script from your email and took at shot at creating
> > libMesaLLVM.so within Mesa.  I've pushed my initial code here:
> > http://cgit.freedesktop.org/~tstellar/mesa/log/?h=libmesallvm
> Thank you very much and sorry for the late reply.
> 
> > I ran into a few minor issues:
> > 
> > I had to export all the LLVM symbols in libMesaLLVM.so, because gallivm
> > still uses some C++ functions, and I was unsure how to handle the name
> > mangling in the linker script.
> You can even add c++ symbols directly there. See
> http://sourceware.org/binutils/docs/ld/VERSION.html
> 

Thanks for pointing this out, I'll look into it.  Do you know if there is
any way to add C++ symbols to the EXPORT() command?

> > Clover still has a number of undefined symbols.  I'm still not quite
> > sure what the problem is, but I think the problem has something
> > to do with the LLVM symbols in the clang libraries clover is using.
> Also not sure, but I assume that some .o files from the .a libs are not pulled 
> because they are unused by the C api. The C api is explicitly pulled in the 
> linker script. Which works around the lack of --whole-archive in the linker 
> script. So, probably these missing symbols do just not end up in the shared 
> library.
> 

Yeah, this was the problem, clang needed symbols that weren't used by
the C API, so they weren't included in libMesaLLVM.so.

> > I didn't do much testing yet, but glxgears works for me with r600g and
> > llvmpipe.
> I tried to test against the driver-isolation piglit test that I sent. But this 
> still fails.
> 
> So, this simplest and least intrusive variant appears not to work as expected.
> Not sure what the exact reason is:
> Either, non versioned symbols take precedence or you cannot shield symbols 
> from different libraries by symbol versions. Keep in mind that this mechanism 
> was invented to maintain backwards compatibility for functions that changed in 
> a newer libc library in a api incompatible way, but still provide the old 
> variant for executables/libraries that linked against an older libc.
> So what remains is either dig deeper there, or we use the much more intrusive 
> explicit Mesa prefix to the C api functions. The direct c++ use is still 
> unsolved then.
> 

Today, I spent some time on this and implemented your solution using the
MesaLLVM prefix on all LLVM functions.  The branch is here:
http://cgit.freedesktop.org/~tstellar/mesa/log/?h=libmesallvm-prefix

It's pretty hacky right now.  Only the r600 driver will build, and I've
commented all the c++ code out of gallivm.  However, it passes your
driver-isolation test and even works with clover as long as clover
links to the stock libLLVM-3.3.so library.

We still need to figure out what to do about he c++ usage.  I think some
of it can be replaced with LLVM C API calls, but we may need to use our own
C wrappers for some of the code.

It seems like the prefixing the LLVM calls may be the way to go, let me
know if you have any suggestions for improvements.

-Tom

> > Also, note that there are 4 new commits in that repo, the first three
> > are just variations from my previous C API patches for drivers/radeon.
> > The biggest change is that I moved the static initializer that calls
> > the llvm_multithreaded* functions into gallivm/lp_bld_misc.cpp
> From my point of view this part is fine.
> 
> > Let me know if you have any questions, concerns or other ideas.
> Currently not.
> Thank you for integrating that all and trying that all out!
> 
> Greetings
> 
> Mathias