RE: [GHC] #13413: GHC HEAD panic: collectNBinders
I know what is going on here. I'm in a meeting all day, but I hope to fix
tomorrow.
Simon
| -Original Message-
| From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf Of
| GHC
| Sent: 11 March 2017 20:12
| Cc: ghc-tick...@haskell.org
| Subject: [GHC] #13413: GHC HEAD panic: collectNBinders
|
| #13413: GHC HEAD panic: collectNBinders
| -+--
| -+---
|Reporter: RyanGlScott| Owner: (none)
|Type: bug|Status: new
|Priority: highest| Milestone: 8.2.1
| Component: Compiler | Version: 8.1
|Keywords: JoinPoints | Operating System:
| Unknown/Multiple
|Architecture: | Type of failure: GHC rejects
| Unknown/Multiple | valid program
| Test Case: |Blocked By:
|Blocking: | Related Tickets:
| Differential Rev(s): | Wiki Page:
| -+--
| -+---
| `repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this
| issue. Trying to build it leads to several `collectNBinders` panics is
| various modules. You can reproduce this by compiling this module:
|
| {{{#!hs
| {-# LANGUAGE BangPatterns #-}
| {-# LANGUAGE MagicHash #-}
| module Data.Repa.Eval.Generic.Seq.Chunked where
|
| import GHC.Exts (Int#, (+#), (*#), (>=#))
|
|
| ---
| -- | Fill a block in a rank-2 array, sequentially.
| --
| -- * Blockwise filling can be more cache-efficient than linear filling
| for
| -- rank-2 arrays.
| --
| -- * The block is filled in row major order from top to bottom.
| --
| fillBlock2
| :: (Int# -> a -> IO ()) -- ^ Update function to write into
| result buffer.
| -> (Int# -> Int# -> a) -- ^ Function to get the value at an (x,
| y) index.
| -> Int# -- ^ Width of the whole array.
| -> Int# -- ^ x0 lower left corner of block to
| fill.
| -> Int# -- ^ y0
| -> Int# -- ^ w0 width of block to fill
| -> Int# -- ^ h0 height of block to fill
| -> IO ()
|
| fillBlock2
| write getElem
| !imageWidth !x0 !y0 !w0 h0
|
| = do fillBlock y0 ix0
| where !x1 = x0 +# w0
| !y1 = y0 +# h0
| !ix0= x0 +# (y0 *# imageWidth)
|
| {-# INLINE fillBlock #-}
| fillBlock !y !ix
| | 1# <- y >=# y1 = return ()
| | otherwise
| = do fillLine1 x0 ix
| fillBlock (y +# 1#) (ix +# imageWidth)
|
| where {-# INLINE fillLine1 #-}
| fillLine1 !x !ix'
| | 1# <- x >=# x1 = return ()
| | otherwise
| = do write ix' (getElem x y)
| fillLine1 (x +# 1#) (ix' +# 1#)
|
| {-# INLINE [0] fillBlock2 #-}
| }}}
|
| This compiles on GHC 8.0.2, but on GHC HEAD:
|
| {{{
| $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs
| [1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o )
| ghc-stage2: panic! (the 'impossible' happened)
|(GHC version 8.1.20170201 for x86_64-unknown-linux):
| collectNBinders
|2
|Call stack:
|CallStack (from HasCallStack):
| prettyCurrentCallStack, called at
| compiler/utils/Outputable.hs:1179:58 in ghc:Outputable
| callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in
| ghc:Outputable
| pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in
| ghc:CoreSyn }}}
|
| Interestingly, compiling this triggers the panic at any optimization
| level, but loading the module into GHCi does not cause it to panic.
|
| This regression was introduced in
| 8d5cf8bf584fd4849917c29d82dcf46ee75dd035
| (Join points).
|
| --
| Ticket URL:
| GHC
Another strictness analysis wrinkle
I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Another strictness analysis wrinkle
Actually, I just had a thought. What if we ran ST computations with a different state token type? Say, State# FakeWorld? Would that let them escape the hack? David FeuerWell-Typed, LLP Original message From: David Feuer Date: 3/15/17 6:38 AM (GMT-05:00) To: GHC developers Subject: Another strictness analysis wrinkle I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
Siddhanathan Shanmugam writes:
>> I would be happy to advise if you would like to pick this up.
>
> Thanks Ben!
>
>> This would mean that Haskell libraries compiled with different flags
>> would not be ABI compatible.
>
> Wait, can we not maintain ABI compatibility if we limit the target
> features using a compiler flag? Sometimes (for performance reasons)
> it's reasonable to request the compiler to only generate SSE
> instructions, even if AVX2 is available on the target. On GCC we can
> use the flag -msse to do just that.
>
I think the reasoning here is the following (please excuse the rather
contrived example): Consider a function f with two variants,
module AvxImpl where
{-# OPTIONS_GHC -mavx #-}
f :: DoubleX4# -> DoubleX4# -> Double
module SseImpl where
{-# OPTIONS_GHC -msse #-}
f :: DoubleX4# -> DoubleX4# -> Double
If we allow GHC to pass arguments with SIMD registers we now have a bit
of a conundrum: The calling convention for AvxImpl.f will require that
we pass the two arguments in YMM registers, whereas SseImpl.f will
be via passed some other means (perhaps two pairs of XMM registers).
In the C world this isn't a problem AFAIK since intrinsic types map
directly to register classes. Consequently, I can look at a C
declaration type,
double f(__m256 x, __m256 y);
and tell you precisely the calling convention that would be used. In
GHC, however, we have an abstract vector model and therefore the calling
convention is determined by which ISA the compiler is targetting.
I really don't know how to fix this "correctly". Currently we assume
that there is a static mapping between STG registers and machine
registers. Giving this up sounds quite painful.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
solution: lets call these registers what they are, instead of pretending
they're portable. we are not going to find the right abstraction in the
first go. lets not do that. first get it working sanely, then figure out
proper abstractions
On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari wrote:
> Siddhanathan Shanmugam writes:
>
> >> I would be happy to advise if you would like to pick this up.
> >
> > Thanks Ben!
> >
> >> This would mean that Haskell libraries compiled with different flags
> >> would not be ABI compatible.
> >
> > Wait, can we not maintain ABI compatibility if we limit the target
> > features using a compiler flag? Sometimes (for performance reasons)
> > it's reasonable to request the compiler to only generate SSE
> > instructions, even if AVX2 is available on the target. On GCC we can
> > use the flag -msse to do just that.
> >
> I think the reasoning here is the following (please excuse the rather
> contrived example): Consider a function f with two variants,
>
> module AvxImpl where
> {-# OPTIONS_GHC -mavx #-}
> f :: DoubleX4# -> DoubleX4# -> Double
>
> module SseImpl where
> {-# OPTIONS_GHC -msse #-}
> f :: DoubleX4# -> DoubleX4# -> Double
>
> If we allow GHC to pass arguments with SIMD registers we now have a bit
> of a conundrum: The calling convention for AvxImpl.f will require that
> we pass the two arguments in YMM registers, whereas SseImpl.f will
> be via passed some other means (perhaps two pairs of XMM registers).
>
> In the C world this isn't a problem AFAIK since intrinsic types map
> directly to register classes. Consequently, I can look at a C
> declaration type,
>
> double f(__m256 x, __m256 y);
>
> and tell you precisely the calling convention that would be used. In
> GHC, however, we have an abstract vector model and therefore the calling
> convention is determined by which ISA the compiler is targetting.
>
> I really don't know how to fix this "correctly". Currently we assume
> that there is a static mapping between STG registers and machine
> registers. Giving this up sounds quite painful.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
Ok so 1) xmm when not using fancy features 2) lets not have types that vary with the abi then! i genuinely think that this is one of those domains where "no abstraction" is a better starting point than "wrong abstraction" I believe both edward kmett and I genuinely want to be users of simd on ghc, and i think in both our cases, it would be markedly simpler to ground the initial work in the ISA / CPU feature level operations/ register flavors rather than trying to get ghc to do the "right abstraction" when we have no experience even trying to bundle it up as a library. Lets get stuff off the ground that doesn't mis-abstract, before we start hunting for the right higher level tools on top. No matter *how* ghc ultimately bundles simd for high level programming, it *will* have to bottom out into these target specific operations at code gen time, and LLVM is *not* an abstraction for it. On Fri, Mar 10, 2017 at 12:50 AM Siddhanathan Shanmugam < siddhanathan+...@gmail.com> wrote: > > It would be even better if we could *also* teach the native back end about > SSE instructions. Is there anyone who might be willing to work on that? > > Yes. Though, it would be better if someone with more experience than me > decides to pick this up instead. > > On Thu, Mar 9, 2017 at 7:00 PM, Edward Kmett wrote: > > If we only turn on ymm and zmm for passing explicit 256bit and 512bit > vector types then changing the ABI would have basically zero effect on any > code anybody is actually using today. Everything would remain abi > compatible unless it involves the new types that nobody is using. > > This also has the benefit that turning on avx2 or avx512 wouldn't change > the calling convention of any code, making it much safer to link code > compiled with it on with code compiled with it off. That seems like a big > deal. > > Moreover, if we start passing normal floats, etc. through them then our > lack of shuffles and ways to get data in/out of them becomes quite a pain > point. > > As for passing int/word data, passing the vectors of them through the ymm > and zmm registers should be sufficient for the same reasons. > > -Edward > > On Thu, Mar 9, 2017 at 3:55 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > > zooming out: > > what *should* the new ABI be? > > Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers > (depending on how they're being used) caller save, > > (what about all 32 zmm registers? would they be float only, or also for > ints/words? simd has lots of nice int support!) > > a) if this doesn't cause any perf regressions i've no objections > > b) currently we only support passing floats/doubles and simd vectors of , > do we wanna support int/word data there too? (or are the GPR / general > purpose registers enough for those? ) > > c) other stuff i'm probably overlooking > > d) lets do this! > > On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > > the patch is still on TRAC, > > https://ghc.haskell.org/trac/ghc/ticket/8033 > > we need to do changes to both the 32bit and 64bit ABIs, and I think thats > where I got stalled from lack of feedback > > that aside: > > heres the original email thread on the llvm commits thread > http://lists.llvm.org/pipermail/llvm-commits/Week- > of-Mon-20130708/180264.html > > and theres links from there to the iterating on the test suite plus the > original patch > > i'm more than happy to take a weekend to do the leg work, it was pretty > fun last time. > > BUT, we need to agree on what ABI to do, and make sure that those ABI > changes dont create a performance regression for some unexpected reason. > > On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland > wrote: > > We would need to get a patch to LLVM accepted to change the GHC calling > convention. > > Now that we commit to a particular version of LLVM, this might be less > of an issue than it once was since we wouldn't have to support versions > of LLVM that didn't support the new calling convention. > > So...how do we get a patch into LLVM? I believe I once had such a patch > ready to go...I will dig around for it, but the change is very small and > easily recreated. > > It would be even better if we could *also* teach the native back end > about SSE instructions. Is there anyone who might be willing to work on > that? > > Geoff > > On 3/9/17 2:30 PM, Edward Kmett wrote: > > Back around 2013, Geoff raised a discussion about fixing up the GHC > > ABI so that the LLVM calling convention could pass 256 bit vector > > types in YMM (and, i suppose now 512 bit vector types in ZMM). > > > > As I recall, this was blocked by some short term concerns about which > > LLVM release was imminent or what have you. Four years on, the exact > > same sort of arguments could be dredged up, but yet in the meantime > > nobody is really using those types for anything. > > > > This still creates a pain point around trying to use these wide types > > today. Spilling rather than passi
Re: LLVM calling convention for AVX2 and AVX512 registers
Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
deliberately crashes out during code generation, no? So this is very
deliberately *not* a problem with the current setup as I understand it. It
only becomes one if we reverse the decision and decide to add terribly
inefficient shims for this functionality at the primop level rather than
have a higher level make the right call to just not use functionality that
isn't present on the target platform.
-Edward
On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari wrote:
> Siddhanathan Shanmugam writes:
>
> >> I would be happy to advise if you would like to pick this up.
> >
> > Thanks Ben!
> >
> >> This would mean that Haskell libraries compiled with different flags
> >> would not be ABI compatible.
> >
> > Wait, can we not maintain ABI compatibility if we limit the target
> > features using a compiler flag? Sometimes (for performance reasons)
> > it's reasonable to request the compiler to only generate SSE
> > instructions, even if AVX2 is available on the target. On GCC we can
> > use the flag -msse to do just that.
> >
> I think the reasoning here is the following (please excuse the rather
> contrived example): Consider a function f with two variants,
>
> module AvxImpl where
> {-# OPTIONS_GHC -mavx #-}
> f :: DoubleX4# -> DoubleX4# -> Double
>
> module SseImpl where
> {-# OPTIONS_GHC -msse #-}
> f :: DoubleX4# -> DoubleX4# -> Double
>
> If we allow GHC to pass arguments with SIMD registers we now have a bit
> of a conundrum: The calling convention for AvxImpl.f will require that
> we pass the two arguments in YMM registers, whereas SseImpl.f will
> be via passed some other means (perhaps two pairs of XMM registers).
>
> In the C world this isn't a problem AFAIK since intrinsic types map
> directly to register classes. Consequently, I can look at a C
> declaration type,
>
> double f(__m256 x, __m256 y);
>
> and tell you precisely the calling convention that would be used. In
> GHC, however, we have an abstract vector model and therefore the calling
> convention is determined by which ISA the compiler is targetting.
>
> I really don't know how to fix this "correctly". Currently we assume
> that there is a static mapping between STG registers and machine
> registers. Giving this up sounds quite painful.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
agreed. and the generic vector size stuff in llvm is both pretty naive, AND
not the sane/tractable way to add SIMD support to the NCG,
i'm totally ok with my vector sizes that are available depending on the
target CPU or whatever. Operating systems have very sane errors for that
sort of mishap,
On Wed, Mar 15, 2017 at 3:29 PM, Edward Kmett wrote:
> Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
> deliberately crashes out during code generation, no? So this is very
> deliberately *not* a problem with the current setup as I understand it.
> It only becomes one if we reverse the decision and decide to add terribly
> inefficient shims for this functionality at the primop level rather than
> have a higher level make the right call to just not use functionality that
> isn't present on the target platform.
>
> -Edward
>
>
> On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari wrote:
>
>> Siddhanathan Shanmugam writes:
>>
>> >> I would be happy to advise if you would like to pick this up.
>> >
>> > Thanks Ben!
>> >
>> >> This would mean that Haskell libraries compiled with different flags
>> >> would not be ABI compatible.
>> >
>> > Wait, can we not maintain ABI compatibility if we limit the target
>> > features using a compiler flag? Sometimes (for performance reasons)
>> > it's reasonable to request the compiler to only generate SSE
>> > instructions, even if AVX2 is available on the target. On GCC we can
>> > use the flag -msse to do just that.
>> >
>> I think the reasoning here is the following (please excuse the rather
>> contrived example): Consider a function f with two variants,
>>
>> module AvxImpl where
>> {-# OPTIONS_GHC -mavx #-}
>> f :: DoubleX4# -> DoubleX4# -> Double
>>
>> module SseImpl where
>> {-# OPTIONS_GHC -msse #-}
>> f :: DoubleX4# -> DoubleX4# -> Double
>>
>> If we allow GHC to pass arguments with SIMD registers we now have a bit
>> of a conundrum: The calling convention for AvxImpl.f will require that
>> we pass the two arguments in YMM registers, whereas SseImpl.f will
>> be via passed some other means (perhaps two pairs of XMM registers).
>>
>> In the C world this isn't a problem AFAIK since intrinsic types map
>> directly to register classes. Consequently, I can look at a C
>> declaration type,
>>
>> double f(__m256 x, __m256 y);
>>
>> and tell you precisely the calling convention that would be used. In
>> GHC, however, we have an abstract vector model and therefore the calling
>> convention is determined by which ISA the compiler is targetting.
>>
>> I really don't know how to fix this "correctly". Currently we assume
>> that there is a static mapping between STG registers and machine
>> registers. Giving this up sounds quite painful.
>>
>> Cheers,
>>
>> - Ben
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
to reiterate: any automated lowering / shimming scheme will hurt any
serious user of simd who isn't treating it as some black box abstraction.
And those are the very users who are equipped to write / design libraries /
ghc improvements that let still *other* users pretend to have a mostly
decent black box abstraction. Our compiler engineering bandwidth is not
enough to start with any automagic in this problem domain that isn't
validated with a model implementation in user space.
On Wed, Mar 15, 2017 at 3:31 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> agreed. and the generic vector size stuff in llvm is both pretty naive,
> AND not the sane/tractable way to add SIMD support to the NCG,
>
> i'm totally ok with my vector sizes that are available depending on the
> target CPU or whatever. Operating systems have very sane errors for that
> sort of mishap,
>
> On Wed, Mar 15, 2017 at 3:29 PM, Edward Kmett wrote:
>
>> Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
>> deliberately crashes out during code generation, no? So this is very
>> deliberately *not* a problem with the current setup as I understand it.
>> It only becomes one if we reverse the decision and decide to add terribly
>> inefficient shims for this functionality at the primop level rather than
>> have a higher level make the right call to just not use functionality that
>> isn't present on the target platform.
>>
>> -Edward
>>
>>
>> On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari
>> wrote:
>>
>>> Siddhanathan Shanmugam writes:
>>>
>>> >> I would be happy to advise if you would like to pick this up.
>>> >
>>> > Thanks Ben!
>>> >
>>> >> This would mean that Haskell libraries compiled with different flags
>>> >> would not be ABI compatible.
>>> >
>>> > Wait, can we not maintain ABI compatibility if we limit the target
>>> > features using a compiler flag? Sometimes (for performance reasons)
>>> > it's reasonable to request the compiler to only generate SSE
>>> > instructions, even if AVX2 is available on the target. On GCC we can
>>> > use the flag -msse to do just that.
>>> >
>>> I think the reasoning here is the following (please excuse the rather
>>> contrived example): Consider a function f with two variants,
>>>
>>> module AvxImpl where
>>> {-# OPTIONS_GHC -mavx #-}
>>> f :: DoubleX4# -> DoubleX4# -> Double
>>>
>>> module SseImpl where
>>> {-# OPTIONS_GHC -msse #-}
>>> f :: DoubleX4# -> DoubleX4# -> Double
>>>
>>> If we allow GHC to pass arguments with SIMD registers we now have a bit
>>> of a conundrum: The calling convention for AvxImpl.f will require that
>>> we pass the two arguments in YMM registers, whereas SseImpl.f will
>>> be via passed some other means (perhaps two pairs of XMM registers).
>>>
>>> In the C world this isn't a problem AFAIK since intrinsic types map
>>> directly to register classes. Consequently, I can look at a C
>>> declaration type,
>>>
>>> double f(__m256 x, __m256 y);
>>>
>>> and tell you precisely the calling convention that would be used. In
>>> GHC, however, we have an abstract vector model and therefore the calling
>>> convention is determined by which ISA the compiler is targetting.
>>>
>>> I really don't know how to fix this "correctly". Currently we assume
>>> that there is a static mapping between STG registers and machine
>>> registers. Giving this up sounds quite painful.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
PSA: perf.haskell.org/ghc temporarily out of order
Hi, a recent change to nofib (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a) broke the perf.haskell.org builder, so we won’t be getting perf warnings until that is fixed. I hope that once its up we will not be faced with a large number of performance changes that we will have to track down. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
Edward Kmett writes:
> Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
> deliberately crashes out during code generation, no?
I very well be missing something, but I don't believe this is true. This
program compiles just fine with merely -fllvm -msse,
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
module Hi where
import GHC.Prim
import GHC.Float
addIt :: DoubleX4# -> DoubleX4# -> DoubleX4#
addIt x y = plusDoubleX4# x y
{-# NOINLINE addIt #-}
It produces the following assembler,,
movupd 0x10(%rbp),%xmm0
movupd 0x0(%rbp),%xmm1
movupd 0x30(%rbp),%xmm2
movupd 0x20(%rbp),%xmm3
addpd %xmm1,%xmm3
addpd %xmm0,%xmm2
movupd %xmm2,0x30(%rbp)
movupd %xmm3,0x20(%rbp)
mov0x40(%rbp),%rax
lea0x20(%rbp),%rbp
jmpq *%rax
The reason for this is that the LLVM code generator just blindly
translates DoubleX4# to LLVM's <4 x double> type. The LLVM code
generator then does whatever it can to produce the code we ask of it,
even if the target doesn't have support for this vector variety.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
Carter Schonwald writes: > solution: lets call these registers what they are, instead of pretending > they're portable. we are not going to find the right abstraction in the > first go. lets not do that. first get it working sanely, then figure out > proper abstractions > I'm not sure I understand what you are suggesting here. Are you suggesting we rename the types and primops in the Haskell interface? Some deeper change in semantics? Their treatment in the compiler backend? Something else entirely? I'm lost. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
It's a bit unclear from this comment whether this statement is a critique of a particular implementation strategy for adding SIMD support to the NCG or a more general reflection on SIMD interfaces. From your later messages I infer the latter in my response; feel free to disregard if I misinterpreted. Carter Schonwald writes: > agreed. and the generic vector size stuff in llvm is both pretty > naive, AND not the sane/tractable way to add SIMD support to the NCG, > I don't see why this is true. I think it's fair to say that the LLVM folks have put a lot more thought into SIMD support than any of us here; consequently I tend to put a fair amount of trust in what they have to say about the matter. Moreover, it seems to me like they came up with a pretty sensible abstraction from which they can produce very good code. Is the abstraction perfect? Of course not; they poke holes where necessary to expose truly platform specific functionality. However, it seems they rarely find it necessary to use these holes: In playing around with Clang I found that almost all of the standard vector operations lowered to the "naive" abstract operations. I don't see why we can't provide a similar approach: provide abstract types and some basic operations (as we already do), supplemented with tailored primops far target-specific functionality. My generally, I think we should have a very good reason before we go off and chart our own course here. > i'm totally ok with my vector sizes that are available depending on the > target CPU or whatever. Operating systems have very sane errors for that > sort of mishap, > If the user wants to be more careful about using precisely the vector support that their target offers then that is their perogative. Unless I'm missing something there is nothing stopping them under the current scheme. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
Carter Schonwald writes: > No matter *how* ghc ultimately bundles simd for high level > programming, it *will* have to bottom out into these target specific > operations at code gen time, and LLVM is *not* an abstraction for it. > I am very interested to hear what you mean by this; please do elaborate. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
Ugh. I apparently had a misunderstanding about how that was compiled.
-Edward
On Wed, Mar 15, 2017 at 5:14 PM, Ben Gamari wrote:
> Edward Kmett writes:
>
> > Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
> > deliberately crashes out during code generation, no?
>
> I very well be missing something, but I don't believe this is true. This
> program compiles just fine with merely -fllvm -msse,
>
> {-# LANGUAGE MagicHash #-}
> {-# LANGUAGE UnboxedTuples #-}
> module Hi where
> import GHC.Prim
> import GHC.Float
>
> addIt :: DoubleX4# -> DoubleX4# -> DoubleX4#
> addIt x y = plusDoubleX4# x y
> {-# NOINLINE addIt #-}
>
> It produces the following assembler,,
>
> movupd 0x10(%rbp),%xmm0
> movupd 0x0(%rbp),%xmm1
> movupd 0x30(%rbp),%xmm2
> movupd 0x20(%rbp),%xmm3
> addpd %xmm1,%xmm3
> addpd %xmm0,%xmm2
> movupd %xmm2,0x30(%rbp)
> movupd %xmm3,0x20(%rbp)
> mov0x40(%rbp),%rax
> lea0x20(%rbp),%rbp
> jmpq *%rax
>
> The reason for this is that the LLVM code generator just blindly
> translates DoubleX4# to LLVM's <4 x double> type. The LLVM code
> generator then does whatever it can to produce the code we ask of it,
> even if the target doesn't have support for this vector variety.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: LLVM calling convention for AVX2 and AVX512 registers
On Wed, Mar 15, 2017 at 5:44 PM, Ben Gamari wrote: > Carter Schonwald writes: > > > No matter *how* ghc ultimately bundles simd for high level > > programming, it *will* have to bottom out into these target specific > > operations at code gen time, and LLVM is *not* an abstraction for it. > > > I am very interested to hear what you mean by this; please do elaborate. > I'm a bit puzzled by this, as this is pretty much the exact kind of abstraction LLVM is intended for as I understand it. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: PSA: perf.haskell.org/ghc temporarily out of order
Joachim Breitner writes: > Hi, > > a recent change to nofib > (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a) > broke the perf.haskell.org builder, so we won’t be getting perf > warnings until that is fixed. > I've pushed the michalt's fix. Thanks for the quick turnaround, michalt! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
