llvm calling convention matters
John Lato
jwlato at gmail.com
Fri Sep 20 22:05:38 UTC 2013
@carter you're completely correct, typed template haskell would be very
nice for this.
I think something like asStatic would be fine. It would be slightly
annoying to not be able to use numeric literals, but it seems like a good
first step at any rate.
It would probably be possible to generate a Static value at runtime via the
ghc api. But perhaps not, I haven't played with the typed template haskell
enough to know.
As to constructions like Static (IORef Int), that seems to capture the
semantics of a global IORef, maybe it could be useful for that sort of
application?
On Sep 20, 2013 3:19 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:
> @John, thats actually close to the sort of near term proposal i've been
> thinking of too!
>
> We could probably make it nicer by using the new typed template haskell
> (which geoff was/is also working on!).
> http://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal
>
> With typed template haskell, couldn't we have something like
>
> asStatic :: alpha -> TExp (Static alpha),
>
> where asStatic is the only way to introduce terms with a type (Static
> alpha)? (ie: we could only introduce static values that are closed, at Th
> time, which would also prevent us from construction a value of type (Static
> alpha) at runtime?)
>
> I think that would be enough to introduce the right compile time Static
> Data property. That would also probably capture the right notion of static
> for a number of other uses cases (I think. Probably would need a type class
> constraint on alpha, to rule out crazy things like Static (IORef Int) or
> the like ).
>
> we'd probably need to also have a fromStatic :: Static a -> a, too.
>
> But you're absolutely right, with a teeny bit of work, we could have at
> least a near term work around like that. Theres probably some subtlties i'm
> overlooking though
>
>
>
>
>
>
> On Fri, Sep 20, 2013 at 2:09 PM, John Lato <jwlato at gmail.com> wrote:
>
>> I think Geoffrey's suggestion is workable, but I wouldn't like it so
>> much. The difficulty is that if you aren't aware of it, it's possible to
>> build up a large system that you discover is unworkable the first time you
>> try to compile it.
>>
>> In that sense it's not too different from Template Haskell staging
>> restrictions, which IIRC exist to deal with exactly this problem.
>>
>> As the necessity of compile-time constants has shown up at least twice, a
>> more principled solution is worth investigating.
>>
>> In the meantime, a horrible hack would be something like:
>>
>> newtype CStatic v = CStatic ExpQ
>> instance Num a => Num ( CStatic a) where
>> fromInteger x = [| x |]
>>
>> and then the value could be spliced at the call site. Staging
>> restrictions would ensure it's available at compile time. I guess the
>> instance decl needs Lift too.
>>
>> Downsides are general hideous-ness, misleading error messages, and the
>> necessity for compiling with template haskell. But you'd get an error if s
>> value isn't a compile-time constant. (Please don't put this in ghc, but
>> it's not so bad as a separate lib).
>>
>> John L.
>> On Sep 19, 2013 3:44 PM, "Geoffrey Mainland" <mainland at apeiron.net>
>> wrote:
>>
>>> 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.schonwald at gmail.com <mailto: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'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
>>> > <mainland at apeiron.net <mailto: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>
>>> > > <mailto: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>>
>>> > > <mailto: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>>>
>>> > > <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
>>> > <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>>>
>>> > > <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
>>> > <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
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130920/1ab3cae8/attachment.htm>
More information about the ghc-devs
mailing list