Re: LLVM calling convention for AVX2 and AVX512 registers

> 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

Re: LLVM calling convention for AVX2 and AVX512 registers

This thread is getting into a broader discussion about target specific intrincsics as user prims vs compiler generated. @ben - ed is talking about stuff like a function call that's using a specific avx2 intrinsic, not the parameterized vector abstraction. LLvm shouldn't be lowering those. ... or

Re: LLVM calling convention for AVX2 and AVX512 registers

On 03/14/2017 04:02 PM, Ben Gamari wrote: > Edward Kmett writes: > >> Hrmm. In C/C++ I can tell individual functions to turn on additional ISA >> feature sets with compiler-specific __attribute__((target("avx2"))) tricks. >> This avoids complains from the compiler when I call

Re: FYI: removing `fibon`

I'm not working on it and do not plan to start again. Looks like fibon never worked and wasn't used for anything, so it should be removed. Still it would make sense to replace this code with something used as part of normal nofib test cases. 2017-03-14 19:59 GMT+01:00 Michal Terepeta

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > Hrmm. In C/C++ I can tell individual functions to turn on additional ISA > feature sets with compiler-specific __attribute__((target("avx2"))) tricks. > This avoids complains from the compiler when I call builtins that aren't > available at my current

FYI: removing `fibon`

Hi all, I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned upstream (no commits in 5 years) and I'm not aware of anyone using it or working on it. At this point I don't think it makes sense to try to revive it - I'd prefer putting the time/effort into getting a few new benchmarks.

Re: LLVM calling convention for AVX2 and AVX512 registers

Hrmm. In C/C++ I can tell individual functions to turn on additional ISA feature sets with compiler-specific __attribute__((target("avx2"))) tricks. This avoids complains from the compiler when I call builtins that aren't available at my current compilation feature level. Perhaps pragmas for the

Re: Removing core-spec.pdf from repository?

On Tue, Mar 14, 2017, at 10:20, Elliot Cameron wrote: > The only loss is the ability to look at changes over time. GHC docs are archived for every version number: https://downloads.haskell.org/~ghc//... So it would remain possible to compare the changes between each release. The only problem

Re: Removing core-spec.pdf from repository?

The only loss is the ability to look at changes over time. If that's an important feature, you could write the files with a commit hash in the name. But that may not be worth it. On Tue, Mar 14, 2017 at 4:38 AM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > It's very helpful

RE: Removing core-spec.pdf from repository?

It's very helpful to have a live, up to date PDF. Not everyone has OTT, which is required to make it. And OTT isn't available on Windows at all :-( Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Phil | Ruffwind | Sent: 14 March 2017

Re: Removing core-spec.pdf from repository?

Hi devs, How about putting it here every release? : https://downloads.haskell.org/~ghc/latest/docs/html/ or https://downloads.haskell.org/~ghc/latest/docs/ `core-spec.pdf` will be helpful. But generating it in Windows is a bit complicated :) Regards, Takenobu 2017-03-14 7:57 GMT+09:00