The compile time is not the issue. I'm working on adding SIMD instructions and experimenting with the LLVM side of things (adding new primtypes / primops). I really just want to add instructions to the LLVM generation for now and leave native SIMD/SSE instructions to someone else.
Addition of these vectorization functions is going to require some new MachOps, once I add a new MachOp, all of the code generators want to know about the new MachOp as well ;-) I really simply want to focus on LLVM generation though. I will keep at the compiler/ghc.cabal.in but it is slowly de-generating … on the plus side, I'm learning the build … right? Paul Monday Parallel Scientific, LLC. paul.mon...@parsci.com On Oct 31, 2011, at 1:04 PM, Ian Lynagh wrote: > On Mon, Oct 31, 2011 at 12:52:59PM -0600, Paul Monday wrote: >> Yeah, I was tracking down the unregistered build semantics …. >> >> Unfortunately, this simply says to the compiler: >> "Don't build USING asm because I'm building on an architecture I don't >> know", it doesn't say "don't build asm (native code generation)". >> >> Perhaps if I unentangle it from compiler/ghc.cabal.in … at least that's >> where I'm at now, but that is not straight-forward either. > > You're trying to reduce the compile-time, presumably? We deliberately > always build everything, but to locally disable it changing ghc.cabal.in > sounds like the right place to start. Then hopefully you'll only need to > remove broken imports, and replace broken function calls with undefined. > I'm not sure how big a task it'll be though, I'm afraid. > > > Thanks > Ian >
_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
