Re: PSA: perf.haskell.org/ghc temporarily out of order

Joachim Breitner writes: > Hi, > > a recent change to nofib > (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a) > broke the perf.haskell.org builder, so we won’t be getting perf > warnings until that is fixed. > I've pushed the michalt's

Re: LLVM calling convention for AVX2 and AVX512 registers

On Wed, Mar 15, 2017 at 5:44 PM, Ben Gamari wrote: > Carter Schonwald writes: > > > No matter *how* ghc ultimately bundles simd for high level > > programming, it *will* have to bottom out into these target specific > > operations at code gen

Re: LLVM calling convention for AVX2 and AVX512 registers

Carter Schonwald writes: > No matter *how* ghc ultimately bundles simd for high level > programming, it *will* have to bottom out into these target specific > operations at code gen time, and LLVM is *not* an abstraction for it. > I am very interested to hear what you

Re: LLVM calling convention for AVX2 and AVX512 registers

It's a bit unclear from this comment whether this statement is a critique of a particular implementation strategy for adding SIMD support to the NCG or a more general reflection on SIMD interfaces. From your later messages I infer the latter in my response; feel free to disregard if I

Re: LLVM calling convention for AVX2 and AVX512 registers

Carter Schonwald writes: > solution: lets call these registers what they are, instead of pretending > they're portable. we are not going to find the right abstraction in the > first go. lets not do that. first get it working sanely, then figure out > proper

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it > deliberately crashes out during code generation, no? I very well be missing something, but I don't believe this is true. This program compiles just fine with merely -fllvm -msse,

PSA: perf.haskell.org/ghc temporarily out of order

Hi, a recent change to nofib (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a) broke the perf.haskell.org builder, so we won’t be getting perf warnings until that is fixed. I hope that once its up we will not be faced with a large number of performance changes that

Re: LLVM calling convention for AVX2 and AVX512 registers

to reiterate: any automated lowering / shimming scheme will hurt any serious user of simd who isn't treating it as some black box abstraction. And those are the very users who are equipped to write / design libraries / ghc improvements that let still *other* users pretend to have a mostly decent

Re: LLVM calling convention for AVX2 and AVX512 registers

agreed. and the generic vector size stuff in llvm is both pretty naive, AND not the sane/tractable way to add SIMD support to the NCG, i'm totally ok with my vector sizes that are available depending on the target CPU or whatever. Operating systems have very sane errors for that sort of mishap,

Re: LLVM calling convention for AVX2 and AVX512 registers

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

Re: LLVM calling convention for AVX2 and AVX512 registers

Ok so 1) xmm when not using fancy features 2) lets not have types that vary with the abi then! i genuinely think that this is one of those domains where "no abstraction" is a better starting point than "wrong abstraction" I believe both edward kmett and I genuinely want to be users of simd on

Re: LLVM calling convention for AVX2 and AVX512 registers

solution: lets call these registers what they are, instead of pretending they're portable. we are not going to find the right abstraction in the first go. lets not do that. first get it working sanely, then figure out proper abstractions On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari

Re: LLVM calling convention for AVX2 and AVX512 registers

Siddhanathan Shanmugam 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

RE: Another strictness analysis wrinkle

Actually, I just had a thought. What if we ran ST computations with a different state token type? Say, State# FakeWorld? Would that let them escape the hack? David FeuerWell-Typed, LLP Original message From: David Feuer Date: 3/15/17 6:38 AM

Another strictness analysis wrinkle

I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP___ ghc-devs mailing list

RE: [GHC] #13413: GHC HEAD panic: collectNBinders

I know what is going on here. I'm in a meeting all day, but I hope to fix tomorrow. Simon | -Original Message- | From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf Of | GHC | Sent: 11 March 2017 20:12 | Cc: ghc-tick...@haskell.org | Subject: [GHC] #13413: GHC HEAD