In terms of normal haskell user experience, would it perhaps be a good ideas to have information like "this inlinable function transitively calls an inlinable function that uses a SIMD primop" in the *.hi files?
that way we can, before code gen time, give a warning that compilation of client module might fail without -fllvm? (whether it fails or not depends on how much inlining actually happens ) On Tue, Sep 24, 2013 at 7:25 AM, Simon Marlow <marlo...@gmail.com> wrote: > Yes - it's really just an aesthetic issue, but I think it would be nice if > we know that there's only one pass where these errors show up, so we don't > have to worry about emitting a helpful "sorry" rather than a panic in other > places too. > > Cheers, > Simon > > > On 23/09/2013 21:52, Geoffrey Mainland wrote: > >> 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<http://www.haskell.org/mailman/listinfo/ghc-devs> >>>> >>> >>> ______________________________**_________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs> >>> >>> >> ______________________________**_________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
