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

[Mathias Fröhlich]

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

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

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

> 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