llvm calling convention matters
Carter Schonwald
carter.schonwald at gmail.com
Thu Sep 19 04:40:52 UTC 2013
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 <mainland at 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 <marlowsd at gmail.com
> > <mailto:marlowsd at 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
> > <mainland at apeiron.net
> > <mailto:mainland at apeiron.net>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at 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
> > > <mainland at apeiron.net
> > <mailto:mainland at apeiron.net>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at apeiron.net>>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at apeiron.net>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at apeiron.net>>>>
> > wrote:
> > >
> > > On 09/11/2013 07:44 PM, Johan Tibell
> > wrote:
> > > > On Wed, Sep 11, 2013 at 4:40 PM,
> > Geoffrey Mainland
> > > <mainland at apeiron.net
> > <mailto:mainland at apeiron.net>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at apeiron.net>>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at apeiron.net>
> > <mailto:mainland at apeiron.net
> > <mailto:mainland at 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
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130919/9cb40a73/attachment.htm>
More information about the ghc-devs
mailing list