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
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
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
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
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)
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
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
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
Geoff,
a prosaic reason why there *might* be a fundamentally breaking change would
be the following idea nathan howell suggested to me this afternoon: change
the Sp and SPLim register so that the X86/x86_64 target can use the CPU's
Push and (maybe) Pop instructions for the stack manipulations,
that said it does occur to me that there is an alternative solution that
may be acceptable for everyone!
what about providing a pseudo compatible way called -fllvm-experimentalAVX
(or something), and simply require that for it to be used, the user has an
llvm Patched with the YMM simd in register
to repeat:
I think no one would have object to having a clearly marked, experimental
-fllvmExpermentalAVX flag that requires building LLVM with a specified
patch, as a way to showcase your multivector work!
that would evade all of my objections (provided avx is still exposed with
normal -fllvm,
If users have to do a custom llvm build, we might as well ask them to
build ghc from source too.
Unless I misunderstood ticket #8033, you were originally quite gung-ho
about changing the LLVM calling conventions to support passing SIMD
vectors of all widths in registers on both x86-32 and -64,
emphasis on very very clear warning
On Thu, Sep 12, 2013 at 3:00 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
after a bit more reflection: as long as we provide a clear warning that
7.8 may at some point no longer work with llvm 3.4, i'm down for the
change. We just need to make
oh, i didn't realize you had already done the work! (bah, i'm sorry, i feel
terrible)
I thought i had communicated ~ a month ago that I was worried about release
engineering interaction with making it impossible to then make a subsequent
changes more thoughtfully because of the LLVM release
after a bit more reflection: as long as we provide a clear warning that 7.8
may at some point no longer work with llvm 3.4, i'm down for the change. We
just need to make it very very clear, that it may stop working. (and have
AVX support via passing on the stack with = 3.3)
before i go and
let me know before the weekend starts so i can make time to help if
need be (unless Austin gives breathing room on merge window for such a
thing)
On Thu, Sep 12, 2013 at 3:03 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
emphasis on very very clear warning
On Thu, Sep 12, 2013
The plan is as I wrote below:
7.8 will only support passing 128-bit SIMD vectors in registers on x86-64.
Other vectors sizes, and all vectors on x86-32, will be passed on the
stack.
There is not enough time for anything else at his point.
Geoff
On 09/12/2013 10:40 PM, Carter Schonwald
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
Can you provide an example of the kind of ABI change you might want for
7.10? Is it mainly using more registers to pass arguments? We're already
using 6 *mm* registers to pass arguments on x86_64. I don't know for
sure, but I would be very surprised if there is code out there that
would benefit
On Wed, Sep 11, 2013 at 3:59 PM, Geoffrey Mainland mainl...@apeiron.netwrote:
I don't see why we should limit ourselves by insisting that the gap
between what the LLVM back-end and the native back-end not grow further.
If we want SIMD, the gap is already quite large. Yes it would be nice to
On 09/11/2013 07:33 PM, Johan Tibell wrote:
On Wed, Sep 11, 2013 at 3:59 PM, Geoffrey Mainland mainl...@apeiron.net
wrote:
I don't see why we should limit ourselves by insisting that the gap
between what the LLVM back-end and the native back-end not grow
further.
If we want
On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland mainl...@apeiron.netwrote:
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
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.
23 matches
Mail list logo
