If you pass a constant, unboxed value to a primop, I assume GHC won't ever bind the argument to a value. So although we have no way to enforce "static const argument" in the type system, if this is a valuable (and experts-only?) operation, I'm not sure it matters that much if the user gets an error at code-generation time complaining about non-const arguments.
Another way to look at it: if we wait until someone enhances the type system to support the notion of static arguments, we will likely never have a bit shuffle primitive. The other option would be to fall back on a different implementation if we saw a non-constant argument. I think that would actually be worse than erroring out, but I'm sure others would disagree. Geoff On 09/19/2013 11:42 AM, Carter Schonwald wrote: > tldr; we can't express / expose the LLVM shuffleVector intrinsic in a > type safe way that will correctly interact with the static argument > requirement for associated code generation. > > > > > On Thu, Sep 19, 2013 at 12:40 AM, Carter Schonwald > <carter.schonw...@gmail.com <mailto:carter.schonw...@gmail.com>> wrote: > > yup, i hit a gap in what we can currently express in haskell > types. We don't have a way of expressing static data! I actually > put ticket on trac noting > this. http://ghc.haskell.org/trac/ghc/ticket/8107 > (note that when i was initially writing the ticket, i incorrectly > thought the int# arg to ghc's prefetch was the locality level > rather than a byte offset) > > Currently GHC has no way of expressing "this argument needs to be > a static compile/codegen time constant" in surface haskell or > core! This means we could at best provide a suite of special cased > operations. (eg: we could provide the inter-lane shuffle for > swapping halves of YMM registers, and the miniature analogue for > XMM), but that would really be missing the point: being able to > write complex algorithms that can work completely in registers! > > the vast majority of the simd shuffle operations have certain > arguments that need to be compile time static values that are used > in the actual code generation. The llvm data model doesn't express > this constraint. This invariant failure was also hit internally > recently via a bug in how GHC generated code for llvm's > memcopy! http://ghc.haskell.org/trac/ghc/ticket/8131 > > If we could express llvm'sshuffleVector > <http://llvm.org/docs/LangRef.html#shufflevector-instruction> > intrinsic in a type safe way, then we could express any of them. I > would be over the moon if we could expose an operation like > shuffleVector, but I dont' think GHC currently can express it in a > type safe way that won't make LLVM vomit. > > I want simd shuffle, but i don't see how to give the fully general > shuffle operations in type safe ways with ghc currently. We need > to add support for some notion of static data first! If theres a > way, i'm all for it, but I don't see such a way. > > I hope that answers your question. that seems to be a deep enough > issue that theres no way to resolve it with simple engineering in > the next few weeks. > > -Carter > > > > > On Wed, Sep 18, 2013 at 9:41 PM, Geoffrey Mainland > <mainl...@apeiron.net <mailto:mainl...@apeiron.net>> wrote: > > 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> > > <mailto: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>> > > <mailto: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>>> > > <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 > <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>>> > > <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 > <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