llvm calling convention matters

Carter Schonwald carter.schonwald at gmail.com
Thu Sep 19 15:42:11 UTC 2013


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.schonwald at 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 <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/1092fe16/attachment.htm>


More information about the ghc-devs mailing list