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

[Mathias Fröhlich]

Hi,

Sorry for these late response. I am in the middle of moving to a new 
appartements coordinating work in the new one and so on.
It might even be that I do have no good network access for a few days ...

On Wednesday, May 01, 2013 17:56:33 Tom Stellard wrote:
> 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?
No, sorry.
To be honest I do not even know if the export command is the right way to go. 
>From the documentation I had expected this to work slightly different, but in 
the end it pulls these symbols and did what I need.
So, this is to work around the --whole-archive problem
If we can teach libtool to take the -Wl,-{no--,}whole-archive argument or 
achieve a similar result, we can skip the EXPORT command. Also listing all the 
llvm libs in the linker script was only to get the small proof of concept hack 
together. It's probably better to take the llvm libraries that we get from the 
configure step and use them on the command line instead of just squashing all 
possible llvm libs in this GROUP line ...

> > > 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.
Ok, that sounds good so far.

> 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.
Yes, I think so.

So, for example, lp_disassemble() would move into something like 
MesaLLVMDisassemble() and lp_bld_debug.cpp would pull the MesaLLVMDisassemble 
function?
Jose, does this fit your plans?

> It seems like the prefixing the LLVM calls may be the way to go, let me
> know if you have any suggestions for improvements.
Not more ideas than are already floating around I think.
Thank you very much for doing all this!

Greetings

Mathias