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 <b...@smart-cactus.org> wrote: > Siddhanathan Shanmugam <siddhanathan+...@gmail.com> 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