We did discuss this, but you may not have been present. If LLVM-only primops show up in a non-LLVM codegen, a "sorry" error is reported telling the user that they need to compile with "-fllvm". Yes, this is not a fantastic solution. Options I see:
1) Live with the error message. 2) Remove all SIMD support until the NCG catches up. 3) Figure out a mechanism that avoids inlining any code containing LLVM-only primops when we're not using the LLVM back end. Maybe you can think of another solution? Geoff On 09/18/2013 02:54 PM, Simon Marlow wrote: > This is slightly problematic. What if we have a wonderful > SIMD-enabled vector library that we compile with -fllvm, and then use > it in a program that isn't compiled with -fllvm, and some of the > wonderful SIMD-enabled functions get inlined? Presumably we get a > panic in the NCG. > > Did we discuss this before? I have vague memories, but don't remember > what the outcome was. > > Cheers, > Simon > > On 12/09/13 03:10, Geoffrey Mainland wrote: >> We support compiling some code with -fllvm and some not in the same >> executable. Otherwise how could users of the Haskell Platform link their >> -fllvm-compiled code with native-codegen-compiled libraries like >> base, etc.? >> >> In other words, the LLVM and native back ends use the same calling >> convention. With my SIMD work, they still use the same calling >> conventions, but the native codegen can never generate code that uses >> SIMD instructions. >> >> Geoff >> >> On 09/11/2013 10:03 PM, Johan Tibell wrote: >>> OK. But that doesn't create a problem for the code we output with the >>> LLVM backend, no? Or do we support compiling some code with -fllvm and >>> some not in the same executable? >>> >>> >>> On Wed, Sep 11, 2013 at 6:56 PM, Geoffrey Mainland >>> <mainl...@apeiron.net <mailto:mainl...@apeiron.net>> wrote: >>> >>> We definitely have interop between the native codegen and the LLVM >>> back >>> end now. Otherwise anyone who wanted to use the LLVM back end >>> would have >>> to build GHC themselves. Interop means that users can install the >>> Haskell Platform and still use -fllvm when it makes a performance >>> difference. >>> >>> Geoff >>> >>> On 09/11/2013 07:59 PM, Johan Tibell wrote: >>> > Do nothing different than you're doing for 7.8, we can sort >>> it out >>> > later. Just put a comment on the primops saying they're >>> LLVM-only. See >>> > e.g. >>> > >>> > >>> > >>> >>> https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181 >>> > >>> > for an example how to add docs to primops. >>> > >>> > I don't think we need interop between the native and the LLVM >>> > backends. We don't have that now do we (i.e. they use different >>> > calling conventions). >>> > >>> > >>> > >>> > On Wed, Sep 11, 2013 at 4:51 PM, Geoffrey Mainland >>> > <mainl...@apeiron.net <mailto:mainl...@apeiron.net> >>> <mailto:mainl...@apeiron.net <mailto:mainl...@apeiron.net>>> >>> wrote: >>> > >>> > On 09/11/2013 07:44 PM, Johan Tibell wrote: >>> > > On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland >>> > <mainl...@apeiron.net <mailto:mainl...@apeiron.net> >>> <mailto:mainl...@apeiron.net <mailto:mainl...@apeiron.net>>> >>> wrote: >>> > > > Do you mean we need a reasonable emulation of the SIMD >>> primops for >>> > > > the native codegen? >>> > > >>> > > Yes. Reasonable in the sense that it computes the right >>> result. >>> > I can >>> > > see that some code might still want to #ifdef (if the >>> fallback isn't >>> > > fast enough). >>> > >>> > Two implications of this requirement: >>> > >>> > 1) There will not be SIMD in 7.8. I just don't have the >>> time. In fact, >>> > what SIMD support is there already will have to be >>> removed if we >>> > cannot >>> > live with LLVM-only SIMD primops. >>> > >>> > 2) If we also require interop between the LLVM back-end and >>> the native >>> > codegen, then we cannot pass any SIMD vectors in >>> registers---they all >>> > must be passed on the stack. >>> > >>> > My plan, as discussed with Simon PJ, is to not support SIMD >>> primops at >>> > all with the native codegen. If there is a strong feeling >>> that >>> > this *is >>> > not* the way to go, the I need to know ASAP. >>> > >>> > Geoff >>> > >>> > >>> > >>> >>> >> > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs