----- 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
