On 09/18/2013 04:49 PM, Carter Schonwald wrote: > I've some thoughts on how to have a better solution, but they are > feasible only on a time scale suitable for 7.10, and not for 7.8. > > a hacky solution we could do for 7.8 perhaps is have a warning that > works as follows: > > either > a) > throw a warning on functions that use the SIMD primops, if that > function is being exported by a module, and that function isn't marked > NOINLINE ? Theres probably a few subtleties to it, and this is just a > naive idea That wouldn't inform the consumers of a module. And for a library like vector, we definitely want to export unfoldings for code that contains SIMD primops. That's the only way to get good code out of the library! > b) somehow put both the -fllvm and -fasm core for inlineable functions > in the .hi file? (this one prevents the most problems, but is probably > the most complex work around we could do). The problem being that there *is* no -fasm code...because the NCG doesn't support SIMD operations. Unless we added a mechanism to have two completely different, but simultaneous, definitions for a function, one for -fasm and one for -fllvm. But that would be a lot of work and couldn't be done for 7.8. > > > its worth noting that the LLVM simd in 7.8, either way, won't support > simd shuffles, which will seriously curtail its general utility, > either way.
You told me you would send me example use cases, type signatures, etc. Did I miss an email? If this is very important to you, was there a particular difficulty you had implementing these primops? > On Wed, Sep 18, 2013 at 4:22 PM, Simon Marlow <marlo...@gmail.com > <mailto:marlo...@gmail.com>> wrote: > > On 18/09/13 20:01, Geoffrey Mainland wrote: > > 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? > > > Those are the three unsatisfactory solutions that I know of. Even > if we did (3), the user still wants to know when that is happening > because they're getting less good code, so you'd want a warning. > > One thing we might try to do is automatically enable -fllvm when > the compilation would otherwise fail. If LLVM isn't installed and > the compilation still fails, it's no worse than failing to compile > the module with the sorry error. > > Simon > > > > 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> > <mailto: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>> > <mailto: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>> > <mailto: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