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> 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's > shuffleVector<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>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>> 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
