Re: LLVM calling convention for AVX2 and AVX512 registers

> 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

Re: LLVM calling convention for AVX2 and AVX512 registers

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

RE: Windows build failing in a new way

Ben Gamari writes: > loneti...@gmail.com writes: > >> Ah great, >> >> Triples again.. I still wonder why it is suddenly an issue. We haven’t >> touched the .m4 file in a while and no one changed libffi either >> right? This is just like last time the normalization bit us.

Re: LLVM calling convention for AVX2 and AVX512 registers

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

Re: LLVM calling convention for AVX2 and AVX512 registers

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

Re: LLVM calling convention for AVX2 and AVX512 registers

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

RE: Windows build failing in a new way

loneti...@gmail.com writes: > Ah great, > > Triples again.. I still wonder why it is suddenly an issue. We haven’t > touched the .m4 file in a while and no one changed libffi either > right? This is just like last time the normalization bit us. Causing > days of broken builds on different targets

LLVM calling convention for AVX2 and AVX512 registers

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

RE: Windows build failing in a new way

Ah great, Triples again.. I still wonder why it is suddenly an issue. We haven’t touched the .m4 file in a while and no one changed libffi either right? This is just like last time the normalization bit us. Causing days of broken builds on different targets while everyone fixed the one they

Re: Windows build failing in a new way

Phyx writes: > My CI server is also reproducing it while I also haven't been able to > locally. Weird indeed. > Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See [1]. Cheers, - Ben [1] https://phabricator.haskell.org/rGHCe901ed1c5d66 signature.asc

Re: Windows build failing in a new way

My CI server is also reproducing it while I also haven't been able to locally. Weird indeed. On Thu, 9 Mar 2017, 17:36 Ben Gamari, wrote: > Simon Peyton Jones via ghc-devs writes: > > > My windows build is more broken than usual. I can't even build

Re: Windows build failing in a new way

Simon Peyton Jones via ghc-devs writes: > My windows build is more broken than usual. I can't even build a GHC. > Please, could someone fix this? I'm getting desperate. This is very odd; Harbormaster is also seeing it but I've been unable to reproduce locally. It seems

Re: Windows build failing in a new way

Checking again, I think something else is wrong I'll have to check later. Sorry, but that commit above is still good. If you are really stuck use that one. Tamar On Thu, 9 Mar 2017, 17:11 Phyx, wrote: > That said, running the build on HEAD it seems that the template

Re: Travis again over time

Hi, Am Dienstag, den 07.03.2017, 14:39 +0100 schrieb Joachim Breitner: > The build would be marked as passing if it were not for > integerConstantFolding which is marked as … fixed this issue. Travis should pass now again. Let’s keep it this way! Greetings, Joachim -- Joachim “nomeata”

Re: Windows build failing in a new way

That said, running the build on HEAD it seems that the template haskell stuff committed today has broken the build again. I'd suggest checking out the commit in my previous email which is just a few hours old. And cleaning ghc-tarballs. As the error you seem to be getting is local. On Thu, 9 Mar

Re: Windows build failing in a new way

Hi Simon, As of this morning the Windows build was working fine https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951 those are my nightly logs for last night at commit a02b80f That error seems to be coming from gcc and not ghc. We did update the crt and

Windows build failing in a new way

My windows build is more broken than usual. I can't even build a GHC. Please, could someone fix this? I'm getting desperate. Simon libtool: compile: C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w

Re: [commit: ghc] master: Add a comment to the mapFB rules (665cefe)

Hi, Am Donnerstag, den 09.03.2017, 15:21 + schrieb Simon Peyton Jones via ghc-devs: > >  +-- The "mapFB" rule optimises compositions of map and > >  +-- the "mapFB/id" rule get rids of 'map id' calls. > >  +-- (Any similarity to the Functor laws for [] is expected.) > > Yes, obviously.  But

RE: [commit: ghc] master: Add a comment to the mapFB rules (665cefe)

| +-- The "mapFB" rule optimises compositions of map and | +-- the "mapFB/id" rule get rids of 'map id' calls. | +-- (Any similarity to the Functor laws for [] is expected.) Yes, obviously. But did you have a use-case, or did you just to this on principle? If you don't have this rule what

RE: Better perf

Interesting! I keep nofib/Simon-nofib-notes for per-benchmark notes on perf. Would you like to add a note for 'binary-trees' pointing to these emails? So if someone later is looking for perf changes in binary-trees, they have some back-pointers to chase up. Thanks Simon | -Original

Re: Better perf

Hi, Am Dienstag, den 07.03.2017, 22:55 + schrieb Simon Peyton Jones via ghc-devs: > > But: binary-trees runtime increases by 5%. > > David: might you look to see if there is any obvious reason for this > regression?  We could just accept it, but it's always good to know > why, and to