[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

[Tom Stellard]

On Wed, Aug 27, 2014 at 03:07:36PM -0700, Ian Romanick wrote:
> On 08/27/2014 02:55 PM, Marek Olšák wrote:
> > Our plan is to always require the latest released version of LLVM
> > because of new features in our LLVM backend that the radeonsi driver
> > depends on to advertise all GL features. Some new features listed for
> > the radeonsi driver in Mesa release notes are only enabled if you have
> > latest LLVM from git/svn.
> 
> I think this underscores the fundamental problem have having such a
> critical, core piece of project infrastructure being completely out of
> the control of the project.  For me, trying to ship a product on which
> people rely, this is an absolute non-starter.
> 

There are a lot of misconceptions in this thread, and I was away last week,
so instead of replying to 20 separate emails, I'm replying here.  

This discussion is about using LLVM IR as a common IR for Mesa.  The challenges
we face in coordinating LLVM and Mesa releases for radeonsi are not relevant.
The uses cases of LLVM for radeonsi and LLVM for a common IR are vastly different.

A better comparison would be with llvmpipe, which still works with LLVM 3.1,
but even llvmpipe uses more LLVM features than would be necessary for a common IR
in Mesa.

For such usage, Mesa would be required to use only two components of the LLVM libraries.
The IR builder functions and the optimization passes.  Both of these can be accessed
with the C API which will never change.

The only reasons for requiring a specific LLVM versions would be:

1. Bug fixes for the IR build functions

  This is very unlikely as the functions just manage data structures and
  have been stable for a while.

2. Bug fixes for optimization passes

  In this case you can still use older versions, you would just need to disable
  the specific optimization pass.

3. Extending the C API to gain access to more optimization passes
4. Better optimizations

  Again, you could still use older versions, you would just get
  less optimized code.

Remember that all the optimizations provided by LLVM are for *common*
code and they are essentially free.  Backend developers would still
need to write their own register allocators, schedulers, and target
specific optimization passes.  And they would still be able to write any
other optimization passes they wanted either operating on LLVM IR or their
own target specific IR.

We could reduce the LLVM dependency even further by letting backends
pick which optimization passes to run, so that core Mesa would only
depend on the IR builder code, which if statically linked would require only
2 libraries which together are about 7 MB.

Most of the LLVM - Mesa dependency problems mentioned in this thread are not
applicable to the LLVM dependencies Mesa would have if using LLVM IR
as a common IR.  In my opinion, whatever dependency issues there might
be are not big enough to ban the use of LLVM in core Mesa, and I don't
want to discourage people from trying to use LLVM IR as a common IR
if they are interested. 

-Tom