llvm calling convention matters

Wed Sep 11 22:26:02 UTC 2013

hey all,

first let me preface by saying I am in favor of breaking and
updating/modernizing the GHC ABI.

I just think that for a number of reasons, it doesn't make sense to do it
for the 7.8 release, but rather start work on it in another month or so, so
we can systematically have a better set of ABI, and keep all the code gens
are first class citizens. (also work out the type system changes need to be
able to correctly use SIMD shuffles, which are currently inexpressible
correctly with GHC's type system. Simd Shuffles are crucial for interesting
levels of SIMD performance!)

the reason I don't want to make the ABI change right now is because then
we'd have to wait until after llvm 3.4 gets released in like 6 months
before giving them another breaking change!
 (OR start baking a LLVM into GHC, which is a leap we're not 100% on,
though theres clear good reasons for why! ).

  Basically, if we make breaking changes to the ABI now (and thus have
split ABI for llvm 3.4HEAD vs earlier), and then we do fixups or more
breakage for 7.10, then when 7.10 rolls around (perhaps late next spring or
sometime in the summer, perhaps?), the only supported llvm version for 7.10
would be LLVM HEAD / 3.5 (which won't be released till some time
thereafter)! Unless we go ahead and break the 3.4 ABI to 7.10 rather than
7.8 abi (whatever that would entai, which would ).  This is assuming the ~
7-8 months between major version releases cycle that LLVM has done of late

additionally, as Johan remarked today on a pending patch of mine, having
operations only work on the llvm backend, and not on the native code gen is
pretty problematical!  see  http://ghc.haskell.org/trac/ghc/ticket/8256

tl;dr : Unless we're throwing away native code gen backend next month, we
probably want to actually not increase their capability gap / current ABI
incompatibility right before 7.8 release. I am willing to help explore
modernizing the native code gens so that they have parity with the llvm
backends. Additionally, boxing ourselves in a corner where for 7.10 the
only llvm with the right ABI will be llvm 3.5 seems totally unacceptable
from an end users / distribution package managers standpoint, and a huge
support headache for the  community.

I've had to help deal with the support headache of the xcode5 clang + ghc
issues on OS X,  A LOT,  in the past 2 months, I'm not keen on deliberately
creating similar support disasters for myself and others.

that said: I absolutely agree that we should fix up the ABI, have a clear
story for XMM, YMM, and ZMM registers, and if you've been following trac
tickets at all, you'll see theres even a type system issue in properly
handling the SIMD shuffles! i briefly sketch out the issue in
http://ghc.haskell.org/trac/ghc/ticket/8107 (last comment)

that said: i'm open to being convinced i'm wrong, and I absolutely
understand your motivations for wanting it now, but I really believe that
doing so right now will create a number of problems that are better off
evaded to begin with

cheers
-Carter

On Wed, Sep 11, 2013 at 5:49 PM, Geoffrey Mainland
<mainland at cs.drexel.edu>wrote:

> Hi Carter,
>
> On 09/06/2013 03:24 PM, Carter Tazio Schonwald wrote:
> > Hey Geoff,
>
> > I'm leary about doing a calling convention change right before the ghc
> > release (and I"m happy to elaborate more on the phone some time) 1)
> > I'd rather we test the patches on llvm locally ourselves before going
> > upstream 2) doing that AVX change on the calling convention now, would
> > make it harder to make a more systematic exploration of calling
> > convention changes post 7.8 release, because we would face either
> > breaking the llvm head/3.4 changes, or having to wait till the next
> > llvm release cycle (3.5?!) to upstream any more systematic
> > changes. (such as adding substantially more SIMD registers to the GHC
> > calling convention!)
> >
> > I understand your likely motivation for wanting the calling convention
> > landing in the 7.8 release, namely it may eke an easy 2x perf boost in
> > your stream fusion libs, i just worry that the change would ultimately
> > cut off our ability to do more aggressive experimentation and
> > improvements (eg more simd registers!) for ghc 7.10 over the next
> > year?
> >
> > on an unrelated note: I will spend some time this weekend given you
> > the various simd operations I want / think are valuable. the low
> > hanging fruit would be figuring out a good haskell type / analogue of
> > the llvm __builtin_shuffle(a,b,c) primop, because that usually should
> > generate decent code. I'll work out the details of this and some other
> > examples and send it your way in the next few days
> >
> > -Carter
>
> Currently, on x86-64 we pass floats, doubles, and 128-bit wide SIMD
> vectors in xmm1-xmm6. I propose that we change the calling conventions
> to pass 256-bit wide SIMD vectors in ymm1-ymm6 and 512-bit wide SIMD
> vectors in zmm1-zmm6. I don't know why GHC doesn't use xmm0 or xmm7, as
> the Linux C calling convention uses xmm0-xmm7. Simon, perhaps you know
> why? I get that we only needed 6 registers originally, F1-F4, D1-D2),
> but why count from one rather than zero?
>
> On x86-32, we pass floats, double, and all SIMD vectors on the stack. I
> propose that we pass 128-bit wide SIMD vectors in xmm0-xmm2, and make
> analogous arrangements for 256- and 512-bit SIMD vectors. We will still
> pass floats and doubles on the stack. This matches the Linux x86 32-bit
> C calling convention.
>
> I think these are fairly conservative changes. I also don't think we
> should be afraid of revising the calling convention for GHC 7.10. Surely
> the LLVM folks won't be upset if we send them one set of patches a year
> instead of one set of patches every two years.
>
> Geoff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130911/dbd7fad7/attachment.htm>