The NCG checks for this, but maybe it would be better to add a check in cmm/CmmCallConv.hs? What do you think?
Geoff On 09/23/2013 06:31 AM, Simon Marlow wrote: > Hey Geoff, > > Sorry for not getting around to reviewing this. I just skimmed the > patches and didn't spot anything obviously bogus. > > Regarding the sorry errors, are primops the only place that we need to > check? Is it possible that the user might try to call a function that > takes a SIMD argument and make the NCG fall over that way? > > Cheers, > Simon > > On 16/09/2013 15:16, Geoffrey Mainland wrote: >> The SIMD branch, available as wip/simd, is ready for review/merge. It >> could use some review---Simon and Simon, I'd be especially grateful if >> you both had a quick look. Some major points: >> >> 1) I have added support for AVX 512, although this is necessarily >> untested. AVX and AVX2 are also both supported. >> >> 2) After the recent churn regarding patching LLVM's GHC calling >> convention, by default only 128-bit wide SIMD vectors are passed in >> registers, and then only on X86_64. There is a "hidden" flag, >> -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that >> assumes all vectors are passed in registers by LLVM. This can be used >> with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, >> we can consider turning it on by default for LLVM 3.4+. This would mean >> that we couldn't mix LLVM <3.3-compiled object files with LLVM >>> 3.4-compiled object files, but I don't see that as much of a problem. >> 3) utils/genprimcode has been hacked up to allow us to write vector >> operations once and have them instantiated at multiple vector types. I'm >> not thrilled with this solution, but after discussing with Simon PJ, >> what I've implemented seems to be the minimal reasonable solution to the >> problem of exploding primop boilerplate. The changes are documented in >> compiler/prelude/primops.txt.pp. >> >> 4) Error handling is sub-optimal. My patch checks to make sure that >> vector primops can be compiled efficiently based on the current set of >> dynamic flags. For example, if -mavx is not specified and the user tries >> to use a primop that adds together two 256-bit wide vectors of >> double-precision elements, the user will see an error message like: >> >> ghc-stage2: sorry! (unimplemented feature or known bug) >> (GHC version 7.7.20130916 for x86_64-unknown-linux): >> 256-bit wide floating point SIMD vector instructions require at >> least -mavx. >> >> This is because the only good place to check for this kind of error is >> during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we >> don't have much of an error handling infrastructure there in contrast to >> when we're working in the typechecking/renaming monad. If there is a >> better way/place to do this, please let me know. >> >> Thanks, >> Geoff >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
