[Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8

[Jose Fonseca]

----- Original Message -----
> On 7/21/12 5:53 AM, Jose Fonseca wrote:
> > ----- Original Message -----
> >> Hi guys
> >>
> >> LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm
> >> libs
> >> defined,
> >
> > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the
> > autoconf code should check conditiionally.
> >
> > BTW, I'll soon commit a change that will stop using mcjit from 3.2
> > onwards (as with the current LLVM 3.2 trunk, AVX is supported by
> > the old jit, which is more stable/polished).
> 
> Is there a long-term plan or theory for which jit we'll be using?
>  Are we just following upstream?  

I see ourselves foremost as consumers of LLVM, so the default answer is: to follow upstream, unless it does not fit our purposes.

> Are the problems of mcjit simply a superset
> of the problems with the old jit?

The only reason we started to look at mcjit was because old jit didn't support avx. But on current trunk (ie llvm-3.2) it does.

To be honest, apart of avx, none of the benefits of mcjit matter to me:
- we're not compiling from a C source file (or any kind of source file), so not sure what GDB integration will bring
and all its shortcomings affect me
- each engine can only compile one module -- huge memory waste
- there are redundant version of the code -- more memory waste
- half baked ELF support
- does not support windows

IMO, mcjit it's not production quality, and progress has been awfully slow.

> I know there are people interested in supporting other arches in
> llvmpipe, so it'd be nice if they knew what to work on.  And
> personally
> the gdb integration bit of mcjit sounds really appealing from a
> support
> perspective.

llvmpipe currently can support both, so it's really their choice.

Jose