On Thu, 2012-07-26 at 07:52 -0700, Jose Fonseca wrote: > ----- 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).
Can you clarify the scope of "will stop using mcjit from 3.2 onwards"? Is that specific to (the Intel AVX extensions?) related matters, or is that a mesa-wide statement? (I am specifically interested in the llvmpipe related parts that Adam touched on below). Thanks, -Will > > > > 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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
