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
