RE: CallStack naming

OK. Let's make sure the wiki page and documentation reflects this. Thanks SImon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Eric | Seidel | Sent: 27 January 2016 18:16 | To: ghc-devs@haskell.org | Subject: Re: CallStack naming | | On

Re: Unexpected lack of change in ghcspeed results

On Wed, Jan 27, 2016 at 5:35 PM, Reid Barton wrote: > Oh! I guess the name ghcspeed was too memorable... and browser bar > autocompletion did the rest. Sorry for the noise! > I noticed that https://perf.haskell.org/ghc/ still says "GHC Speed" in the page title and the page

Re: More aggressive dictionary removal?

Hah! I had misread the signatures in the Core output. I'm getting exactly the dictionary removal I wanted. Fantastic! I'm attaching my sample source code and the Core it produces. Sorry for the misdirection, and kudos for specialis/zation in GHC! -- Conal On Thu, Jan 28, 2016 at 4:54 AM, Simon

GHC build time graphs

Joachim, Anthony Cowley was recently complaining on Twitter that building GHC takes 39.5% longer now than it did for 7.10.1: https://twitter.com/a_cowley/status/692481516744634368 Do we have graphs for these metrics, e.g. can we see the breakdown of which commits increased the build time?

Re: Unexpected lack of change in ghcspeed results

Hi, Am Donnerstag, den 28.01.2016, 13:08 -0500 schrieb Reid Barton: > On Wed, Jan 27, 2016 at 5:35 PM, Reid Barton wrote: > > Oh! I guess the name ghcspeed was too memorable... and browser bar > > autocompletion did the rest. Sorry for the noise! > > > I noticed that

Re: GHC build time graphs

Hi, Am Donnerstag, den 28.01.2016, 10:30 -0800 schrieb Edward Z. Yang: > Anthony Cowley was recently complaining on Twitter that > building GHC takes 39.5% longer now than it did for 7.10.1: > https://twitter.com/a_cowley/status/692481516744634368 > > Do we have graphs for these metrics, e.g.

Re: GHC build time graphs

Hi Oleg, Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: > Is the same compiler used to build HEAD and 7.10,1? Good call. In fact, no: 7.10.1 is built with 7.6.3, while HEAD is built with 7.10.3. Anthony’s link, i.e.

Re: GHC build time graphs

Is the same compiler used to build HEAD and 7.10,1? - Oleg > On 28 Jan 2016, at 20:30, Edward Z. Yang wrote: > > Joachim, > > Anthony Cowley was recently complaining on Twitter that > building GHC takes 39.5% longer now than it did for 7.10.1: >

Re: GHC build time graphs

Joachim Breitner writes: > Hi Oleg, > > Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: >> Is the same compiler used to build HEAD and 7.10,1? > > Good call. In fact, no: 7.10.1 is built with 7.6.3, while HEAD is built > with 7.10.3. > > Anthony’s link,

Re: a reliable way of dropping levity args?

I finally had some time to have another look. I have this line in my compiler pass: | Just (tc, args) <- splitTyConApp_maybe ty , isUnboxedTupleTyCon tc = pprTrace "elimUbxSumRepTypes" (text "orig args:" <+> ppr args $$ text "dropWhile isLevityTy args = " <+> ppr

Adding a "release" setting in build.mk.sample (and some other build system questions)

I'm trying to figure out how to generate a release build. I thought it should be "perf" setting, but then I realized ghc-stage1 is called with -O (instead of -O2) when building stage2 with perf setting. So either perf is not the release setting, or I need stage3 which is probably compiled with

Re: a reliable way of dropping levity args?

Ahh, levity is type of kinds, right? For some reason I thought kinds are now levities (or whatever it's called). This makes sense. I just tried and I think it works, thanks. 2016-01-28 19:39 GMT-05:00 Richard Eisenberg : > > On Jan 28, 2016, at 5:48 PM, Ömer Sinan Ağacan

Re: a reliable way of dropping levity args?

It might be nice to actually replace `drop (length args `div` 2) args` with a function `dropLevityArgs = dropWhile (isLevityTy . typeKind)` (I did this in my branch). When I see a code that drops half of the type arguments it doesn't make sense right away, but `dropLevityArgs` is at least giving

Re: a reliable way of dropping levity args?

On Jan 28, 2016, at 5:48 PM, Ömer Sinan Ağacan wrote: > >| Just (tc, args) <- splitTyConApp_maybe ty >, isUnboxedTupleTyCon tc >= pprTrace "elimUbxSumRepTypes" >(text "orig args:" <+> ppr args $$ > text "dropWhile isLevityTy args = " <+> ppr

Re: Adding a "release" setting in build.mk.sample (and some other build system questions)

https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration On Fri, Jan 29, 2016 at 12:50 AM, Ömer Sinan Ağacan wrote: > I'm trying to figure out how to generate a release build. I

Re: More aggressive dictionary removal?

The best way I know is to put INLINABLE on all functions with dictionaries that you want removed. That's what we do in e.g. containers. The pragma is perhaps a bit misnamed, as it doesn't only imply that we make the source of the function available for inlining, but also that we specialize the

RE: More aggressive dictionary removal?

Aggressive inlining is one way, but specialisation ought to get a long way, and makes fewer copies of the specialised code. It’s hard to help without a concrete example Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 28 January 2016 00:05 To:

Re: More aggressive dictionary removal?

I think the difference between the inlinable and specialize pragma is whether the specialization needs to be driven by the call site or not. If you have a handful of known types you want to specialize for up front, you can use the specialize pragma. If the set is large or unknown (like in the case

RE: More aggressive dictionary removal?

I think the difference between the inlinable and specialize pragma is whether the specialization needs to be driven by the call site or not. If you have a handful of known types you want to specialize for up front, you can use the specialize pragma. If the set is large or unknown (like in the

Re: a reliable way of dropping levity args?

Levity is very simple: > data Levity = Lifted | Unlifted And that's it, as far as Levity is concerned. The weird thing is TYPE, whose type is Levity -> TYPE 'Lifted. (Yes. TYPE's type mentions TYPE.) The * of yore is now spelled TYPE 'Lifted. The # of yore is now spelled TYPE 'Unlifted. * and