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
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
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>;
<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
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
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,
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
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
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
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
:* Ben Gamari <bgam...@gmail.com>; Reid Barton <rwbar...@gmail.com>
> *Cc:* ghc-devs <ghc-devs@haskell.org>
> *Subject:* Static data and RULES
>
>
>
> Ben Gamari and Reid Barton are interested in making it cheaper for static
> data to pass through simplification. T
-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David Feuer
Sent: 16 February 2017 22:13
To: Ben Gamari <bgam...@gmail.com>; Reid Barton <rwbar...@gmail.com>
Cc: ghc-devs <ghc-devs@haskell.org>
Subject: Static data and RULES
Ben Gamari and Reid Barton are interested in
: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
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
Ben Gamari and Reid Barton are interested in making it cheaper for static
data to pass through simplification. The basic idea is that if a term is
already made entirely of data constructors and literals, then there's
nothing left to optimize.
However, RULES are allowed to match on data
15 matches
Mail list logo