Re: Static data and RULES

oblem solved. > Simon > > From: David Feuer [mailto:david.fe...@gmail.com] > Sent: 17 February 2017 00:30 > To: Simon Peyton Jones <simo...@microsoft.com> > Cc: ghc-devs <ghc-devs@haskell.org>; Reid Barton <rwbar...@gmail.com>; Ben > Gamari <bgam...@gmail.com

RE: Static data and RULES

Simon Peyton Jones writes: > PS: before we go to some effort to optimise X, can we > I briefly characterized this earlier this week. For a module exporting lots of static data of roughly the same type as TypeRep (e.g. data T = T Addr# Int# Int), the cost scales

Re: Static data and RULES

kLCon1 x = LCon2 #-} > > > Problem solved. > Simon > > From: David Feuer [mailto:david.fe...@gmail.com] > Sent: 17 February 2017 00:30 > To: Simon Peyton Jones <simo...@microsoft.com> > Cc: ghc-devs <ghc-devs@haskell.org>; Reid Barton <rwbar...@gmail.com>;

RE: Static data and RULES

<bgam...@gmail.com> Subject: RE: Static data and RULES Let me give an example. Suppose we have data L = LCon1 Int | LCon2 data S = SCon !Int {-# RULES "L" LCon1 0 = LCon2 "S" forall x . f (SCon x) = g x #-} The immediate problem today is with "S". The SCon wrappe

RE: Static data and RULES

mkLCon1 x = LCon2 #-} Problem solved. Simon From: David Feuer [mailto:david.fe...@gmail.com] Sent: 17 February 2017 00:30 To: Simon Peyton Jones <simo...@microsoft.com> Cc: ghc-devs <ghc-devs@haskell.org>; Reid Barton <rwbar...@gmail.com>; Ben Gamari <bgam...@gmail.com> Subje

Re: Static data and RULES

David Feuer writes: > On Friday, February 17, 2017 12:33:12 AM EST Simon Peyton Jones via ghc-devs > wrote: >> The "L" rule becomes problematic when we try to identify static data the >> simplifier shouldn't have to try to optimize. If it identifies LCon 0 as >> static,

Re: Static data and RULES

On Friday, February 17, 2017 12:33:12 AM EST Simon Peyton Jones via ghc-devs wrote: > The "L" rule becomes problematic when we try to identify static data the > simplifier shouldn't have to try to optimize. If it identifies LCon 0 as > static, the "L" rule will never fire. > Why doesn’t it

RE: Static data and RULES

avid.fe...@gmail.com>] Sent: 16 February 2017 23:51 To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> Cc: ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>>; Reid Barton <rwbar...@gmail.com<mailto:rwbar...@gmail.com>>; Ben Gamar

RE: Static data and RULES

euer [mailto:david.fe...@gmail.com] >> *Sent:* 16 February 2017 23:51 >> *To:* Simon Peyton Jones <simo...@microsoft.com> >> *Cc:* ghc-devs <ghc-devs@haskell.org>; Reid Barton <rwbar...@gmail.com>; >> Ben Gamari <bgam...@gmail.com> >> *Subjec

RE: Static data and RULES

Reid Barton <rwbar...@gmail.com>; > Ben Gamari <bgam...@gmail.com> > *Subject:* RE: Static data and RULES > > > > Sorry; guess I should have given more background on that. This goes back > to the performance problems Ben encountered in Typeable. The goal is to > avo

RE: Static data and RULES

Sorry; guess I should have given more background on that. This goes back to the performance problems Ben encountered in Typeable. The goal is to avoid trying to optimize something over and over that's never ever going to change. If we know that a term is made only of static data, we can skip it

RE: Static data and RULES

I don’t understand any of this. However, RULES are allowed to match on data constructors and it would be nice to let that keep happening. Why won’t it keep happening? What is the problem you are trying to solve? Why does the fast-path make it harder? Maybe open a ticket? Simon From:

Re: Static data and RULES

:20 PM (GMT-05:00) To: ghc-devs@haskell.org Subject: Re: Static data and RULES Hi, Am Donnerstag, den 16.02.2017, 17:12 -0500 schrieb David Feuer: > Strict constructor wrappers will all be allowed to inline after > demand analysis and worker/wrapper. This matches the way we now > handle wr

Re: Static data and RULES

Hi, Am Donnerstag, den 16.02.2017, 17:12 -0500 schrieb David Feuer: > Strict constructor wrappers will all be allowed to inline after > demand analysis and worker/wrapper. This matches the way we now > handle wrappers actually created in that phase. I am worried that DmdAnal will be less