FW: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins in Core Lint

[Simon Peyton Jones via ghc-devs]

perf/haddock.base and haddock.Cabal have improved, hence failure here..   am 
building with HADDOCK_DOCS on.  If someone else gets there first, be my guest

From: nore...@phabricator.haskell.org [mailto:nore...@phabricator.haskell.org]
Sent: 16 February 2017 16:08
To: Simon Peyton Jones 
Subject: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins 
in Core Lint

Harbormaster failed to build B13964: rGHC6bab649bde65: Improve checking of 
joins in Core Lint!


BRANCHES
master

USERS
simonpj (Author)

COMMIT
https://phabricator.haskell.org/rGHC6bab649bde65

EMAIL PREFERENCES
https://phabricator.haskell.org/settings/panel/emailpreferences/

To: simonpj, Harbormaster
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Better perf for haddock.base, haddock.Cabal (f4aa998)

[Joachim Breitner]

Hi,

Am Donnerstag, den 16.02.2017, 17:46 + schrieb g...@git.haskell.org:
> commit f4aa9984790332a908e8b1321d00a839fb42c3ea
> Author: Simon Peyton Jones 
> Date:   Thu Feb 16 17:44:58 2017 +
> 
> Better perf for haddock.base, haddock.Cabal
> 
> I think this is due to
>   commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a
>   Author: Simon Peyton Jones 
>   Date:   Thu Feb 16 09:42:32 2017 +
> 
>   Improve checking of joins in Core Lint
> 
> Improvement is around 5%.

no,
https://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b9969f
clearly points to this commit:

commit fc9d152b058f21ab03986ea722d0c94688b9969f
Author: Simon Peyton Jones 
Date:   Thu Feb 16 09:41:55 2017 +

Comments and tiny refactor only

Which is not just a refactoring. If you look at the diff, e.g. at
https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b9969f
you will see that after your change, the “one shot arguments according
to the environment” are no longer counted towards n_val_args in
fun_uds and is_exp. And it seems they should not! Is that something you
understand and can explain in a note?

I guess https://phabricator.haskell.org/D3089 was merged a bit
prematurely in that respect.¹

Greetings,
Joachim


¹ There is a workflow problem with Phab’s DR:
  * A creates a new DR.
  * B requests changes. DR now in state “revision needed”
  * C requests changes. DR still in state “revision needed”
  * A makes changes. DR now in state “needs review”
  * C looks at the changes and finds his concern addressed
and accepts the revision. DR now in state “accepted”.
  * G comes along, sees a DR in state “accepted” and lands it.
  Problem: B did not have the chance to check the new revision.


  



-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Better perf for haddock.base, haddock.Cabal (f4aa998)

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
...
>
> I guess https://phabricator.haskell.org/D3089 was merged a bit
> prematurely in that respect.¹
>
> Greetings,
> Joachim
>
>
> ¹ There is a workflow problem with Phab’s DR:
>   * A creates a new DR.
>   * B requests changes. DR now in state “revision needed”
>   * C requests changes. DR still in state “revision needed”
>   * A makes changes. DR now in state “needs review”
>   * C looks at the changes and finds his concern addressed
> and accepts the revision. DR now in state “accepted”.
>   * G comes along, sees a DR in state “accepted” and lands it.
>   Problem: B did not have the chance to check the new revision.
>
Actually, the problem in this particular case was the Simon left
comments but didn't request changes. Had he done so the Diff wouldn't
have entered "accepted" state until he accepted. Sorry if I had been a
bit premature in merging this one.

While I understand why this is the case, it can be a bit unfortunate in
the case of an open-source project, where a drive-by reviewer might
leave a comment, the author makes the requested change, and the reviewer
never returns to accept the change. In this case the Diff remains in a
sort of limbo, even if someone else accepts it.

This is to some extent a social problem: In an ideal world reviewers
would continue to submit reviews until the patch is merged. However, in
the case of a project like GHC this is rarely the case. For this reason
I sometimes need to ping reviewers and explicitly ask them to accept
changes.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Static data and RULES

[David Feuer]

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 constructors and it would be
nice to let that keep happening. But on the other hand, RULES are
apparently (according to Duncan Coutts) already broken for strict data
constructors, because they have workers and wrappers.

My thought: let's allow phased INLINE and NOINLINE pragmas for data
constructors. The default would be INLINE. The ~ phase choice would not be
available: once inline, always inline.

Semantics
~~

For all constructors:

If a constructor is allowed by pragmas to inline in a certain phase, then
in that phase terms built from it can be considered static. Once static,
always static.

If a constructor is not allowed to inline in a certain phase, terms built
from it will be considered non-static.

After demand analysis and worker/wrapper, all constructors are considered
inline.

For strict constructors:

A strict constructor wrapper prohibited from inlining in a certain phase
simply will not.

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.

Syntax:

For GADT syntax, this is easy:

data Foo ... where
  {-# INLINE [1] Bar #-}
  Bar :: ...

For traditional syntax, I think it's probably best to pull the pragmas to
the top:

{-# NOINLINE Quux #-}
data Baz ... = Quux ... | ...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DR workflows

[Joachim Breitner]

Hi

Am Donnerstag, den 16.02.2017, 17:01 -0500 schrieb Ben Gamari:
> > ¹ There is a workflow problem with Phab’s DR:
> >   * A creates a new DR.
> >   * B requests changes. DR now in state “revision needed”
> >   * C requests changes. DR still in state “revision needed”
> >   * A makes changes. DR now in state “needs review”
> >   * C looks at the changes and finds his concern addressed
> > and accepts the revision. DR now in state “accepted”.
> >   * G comes along, sees a DR in state “accepted” and lands it.
> >   Problem: B did not have the chance to check the new revision.
> > 
> 
> Actually, the problem in this particular case was the Simon left
> comments but didn't request changes. Had he done so the Diff wouldn't
> have entered "accepted" state until he accepted.

Indeed! I thought I saw “Simon requested changes“ in this one, but my
memory was failing me here. So I partly retract my fussmaking here.


> While I understand why this is the case, it can be a bit unfortunate in
> the case of an open-source project, where a drive-by reviewer might
> leave a comment, the author makes the requested change, and the reviewer
> never returns to accept the change. In this case the Diff remains in a
> sort of limbo, even if someone else accepts it.

Would it not at least show up on Phab’s starting page, under “Ready to
Review” or some of the other categories. In the worst case, the author
can ping the reviewer here. I think it is fine that if someone requests
changes to expect him to follow up. The drive-by reviewer should leave
comments without requesting changes then.

> This is to some extent a social problem: In an ideal world reviewers
> would continue to submit reviews until the patch is merged. However, in
> the case of a project like GHC this is rarely the case. For this reason
> I sometimes need to ping reviewers and explicitly ask them to accept
> changes.

This is fine, I think.


What I sometimes miss as a reviewer is to indicate: “As far as I am
concerned, this looks good, but I did not review the whole thing”, for
example if one aspect of a change interacts with “my” code in GHC, and
I verified that this part is ok.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Static data and RULES

[Joachim Breitner]

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 effective the code it sees does
not have the wrappers of strict constructors already inlines. It may be
that the strictness signature of the wrapper is sufficient to make up
for this, but I am not sure.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Static data and RULES

[David Feuer]

The vast majority would have no pragma, or at least wouldn't have an unphased 
NOINLINE pragma, so they would typically inline before demand analysis anyway.


David FeuerWell-Typed, LLP 
 Original message From: Joachim Breitner 
 Date: 2/16/17  5: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 wrappers actually created in that phase.

I am worried that DmdAnal will be less effective the code it sees does
not have the wrappers of strict constructors already inlines. It may be
that the strictness signature of the wrapper is sufficient to make up
for this, but I am not sure.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Better perf for haddock.base, haddock.Cabal (f4aa998)

[Simon Peyton Jones via ghc-devs]

| clearly points to this commit:
| 
| commit fc9d152b058f21ab03986ea722d0c94688b9969f
| Author: Simon Peyton Jones 
| Date:   Thu Feb 16 09:41:55 2017 +
| 
| Comments and tiny refactor only

Crumbs!  You are right!

I have NO IDEA why this effect is so large.  I fixed the bug in occAnalApp
when I was auditing your changes, but I couldn't think of a situation in which
I would matter, and then I forgot all about it.

It's hard to add a comment both the call to mkOneOcc and isExpandableApp 
were designed for the number of args the function is *syntactically* applied 
to.  But the argOneShots needs how many it is *semantically* applied to, once.

But is_exp only matters if isRhsEnv is true; and in that case I think 
occ_one_shots is empty (see rhsCtxt); so I doubt the change to is_exp makes any 
difference at all.

It's a mystery.  Ideally one would find out why.  But life is short, and this 
is in the right direction.

I've added a note to the ticket, FWIW

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Joachim
| Breitner
| Sent: 16 February 2017 20:41
| To: ghc-devs@haskell.org
| Subject: Re: Better perf for haddock.base, haddock.Cabal (f4aa998)
| 
| Hi,
| 
| Am Donnerstag, den 16.02.2017, 17:46 + schrieb g...@git.haskell.org:
| > commit f4aa9984790332a908e8b1321d00a839fb42c3ea
| > Author: Simon Peyton Jones 
| > Date:   Thu Feb 16 17:44:58 2017 +
| >
| > Better perf for haddock.base, haddock.Cabal
| >
| > I think this is due to
| >   commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a
| >   Author: Simon Peyton Jones 
| >   Date:   Thu Feb 16 09:42:32 2017 +
| >
| >   Improve checking of joins in Core Lint
| >
| > Improvement is around 5%.
| 
| no,
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperf.has
| kell.org%2Fghc%2F%23revision%2Ffc9d152b058f21ab03986ea722d0c94688b9969f&d
| ata=02%7C01%7Csimonpj%40microsoft.com%7Caacdd3c960ea4e56ea6c08d456ac2c5d%
| 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636228744888337816&sdata=vZW
| XXwyBzBcUMliVMtS9vUFmlQuBXOhciC9uzSm7aW0%3D&reserved=0
| clearly points to this commit:
| 
| commit fc9d152b058f21ab03986ea722d0c94688b9969f
| Author: Simon Peyton Jones 
| Date:   Thu Feb 16 09:41:55 2017 +
| 
| Comments and tiny refactor only
| 
| Which is not just a refactoring. If you look at the diff, e.g. at
| 
| https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b99
| 69f
| you will see that after your change, the “one shot arguments according to
| the environment” are no longer counted towards n_val_args in fun_uds and
| is_exp. And it seems they should not! Is that something you understand
| and can explain in a note?
| 
| I guess https://phabricator.haskell.org/D3089 was merged a bit
| prematurely in that respect.¹
| 
| Greetings,
| Joachim
| 
| 
| ¹ There is a workflow problem with Phab’s DR:
|   * A creates a new DR.
|   * B requests changes. DR now in state “revision needed”
|   * C requests changes. DR still in state “revision needed”
|   * A makes changes. DR now in state “needs review”
|   * C looks at the changes and finds his concern addressed
| and accepts the revision. DR now in state “accepted”.
|   * G comes along, sees a DR in state “accepted” and lands it.
|   Problem: B did not have the chance to check the new revision.
| 
| 
| 
| 
| 
| 
| --
| Joachim “nomeata” Breitner
|   m...@joachim-breitner.de •
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joac
| him-
| breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Caacdd3c960ea4e56e
| a6c08d456ac2c5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636228744888
| 337816&sdata=vsGnQwAfqS%2B0hfL0ZLwnDy87eNSBeLltJQXqPOadnXo%3D&reserved=0
|   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
|   Debian Developer: nome...@debian.org
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Static data and RULES

[Simon Peyton Jones via ghc-devs]

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: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David Feuer
Sent: 16 February 2017 22:13
To: Ben Gamari ; Reid Barton 
Cc: ghc-devs 
Subject: Static data and RULES

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 constructors and it would be nice 
to let that keep happening. But on the other hand, RULES are apparently 
(according to Duncan Coutts) already broken for strict data constructors, 
because they have workers and wrappers.

My thought: let's allow phased INLINE and NOINLINE pragmas for data 
constructors. The default would be INLINE. The ~ phase choice would not be 
available: once inline, always inline.

Semantics
~~

For all constructors:

If a constructor is allowed by pragmas to inline in a certain phase, then in 
that phase terms built from it can be considered static. Once static, always 
static.

If a constructor is not allowed to inline in a certain phase, terms built from 
it will be considered non-static.

After demand analysis and worker/wrapper, all constructors are considered 
inline.

For strict constructors:

A strict constructor wrapper prohibited from inlining in a certain phase simply 
will not.

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.

Syntax:

For GADT syntax, this is easy:

data Foo ... where
  {-# INLINE [1] Bar #-}
  Bar :: ...

For traditional syntax, I think it's probably best to pull the pragmas to the 
top:

{-# NOINLINE Quux #-}
data Baz ... = Quux ... | ...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Static data and RULES

[David Feuer]

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
altogether in simplification. Suppose we have

foo = Just (Right [1])

Then no amount of optimization will ever be useful. But what about RULES?
If the outermost pattern in a rule matches on a data constructor, then it's
not static anymore! We may be replacing it with something else. So we need
a finer mechanism. We *also* need a finer mechanism for strict constructors
in general. We need to avoid inlining those too early if they're mentioned
in any position in RULES. Trying to make this work right automagically
looks a bit tricky in the face of orphan rules and such.

On Feb 16, 2017 6:35 PM, "Simon Peyton Jones"  wrote:

> 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:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *David
> Feuer
> *Sent:* 16 February 2017 22:13
> *To:* Ben Gamari ; Reid Barton 
> *Cc:* ghc-devs 
> *Subject:* Static data and RULES
>
>
>
> 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 constructors and it would be
> nice to let that keep happening. But on the other hand, RULES are
> apparently (according to Duncan Coutts) already broken for strict data
> constructors, because they have workers and wrappers.
>
>
>
> My thought: let's allow phased INLINE and NOINLINE pragmas for data
> constructors. The default would be INLINE. The ~ phase choice would not be
> available: once inline, always inline.
>
>
>
> Semantics
>
> ~~
>
>
>
> For all constructors:
>
>
>
> If a constructor is allowed by pragmas to inline in a certain phase, then
> in that phase terms built from it can be considered static. Once static,
> always static.
>
>
>
> If a constructor is not allowed to inline in a certain phase, terms built
> from it will be considered non-static.
>
>
>
> After demand analysis and worker/wrapper, all constructors are considered
> inline.
>
>
>
> For strict constructors:
>
>
>
> A strict constructor wrapper prohibited from inlining in a certain phase
> simply will not.
>
>
>
> 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.
>
>
>
> Syntax:
>
>
>
> For GADT syntax, this is easy:
>
>
>
> data Foo ... where
>
>   {-# INLINE [1] Bar #-}
>
>   Bar :: ...
>
>
>
> For traditional syntax, I think it's probably best to pull the pragmas to
> the top:
>
>
>
> {-# NOINLINE Quux #-}
>
> data Baz ... = Quux ... | ...
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Static data and RULES

[Simon Peyton Jones via ghc-devs]

I’m sorry I still don’t understand the problem.  Can you give an example?  It 
all works fine today; what will change in the proposed new scheme.  Indeed what 
IS the proposed new scheme?

I’m lost

Simon

From: David Feuer [mailto:david.fe...@gmail.com]
Sent: 16 February 2017 23:51
To: Simon Peyton Jones 
Cc: ghc-devs ; Reid Barton ; Ben 
Gamari 
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 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 altogether in 
simplification. Suppose we have

foo = Just (Right [1])

Then no amount of optimization will ever be useful. But what about RULES? If 
the outermost pattern in a rule matches on a data constructor, then it's not 
static anymore! We may be replacing it with something else. So we need a finer 
mechanism. We *also* need a finer mechanism for strict constructors in general. 
We need to avoid inlining those too early if they're mentioned in any position 
in RULES. Trying to make this work right automagically looks a bit tricky in 
the face of orphan rules and such.

On Feb 16, 2017 6:35 PM, "Simon Peyton Jones" 
mailto:simo...@microsoft.com>> wrote:
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: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of David Feuer
Sent: 16 February 2017 22:13
To: Ben Gamari mailto:bgam...@gmail.com>>; Reid Barton 
mailto:rwbar...@gmail.com>>
Cc: ghc-devs mailto: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. 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 constructors and it would be nice 
to let that keep happening. But on the other hand, RULES are apparently 
(according to Duncan Coutts) already broken for strict data constructors, 
because they have workers and wrappers.

My thought: let's allow phased INLINE and NOINLINE pragmas for data 
constructors. The default would be INLINE. The ~ phase choice would not be 
available: once inline, always inline.

Semantics
~~

For all constructors:

If a constructor is allowed by pragmas to inline in a certain phase, then in 
that phase terms built from it can be considered static. Once static, always 
static.

If a constructor is not allowed to inline in a certain phase, terms built from 
it will be considered non-static.

After demand analysis and worker/wrapper, all constructors are considered 
inline.

For strict constructors:

A strict constructor wrapper prohibited from inlining in a certain phase simply 
will not.

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.

Syntax:

For GADT syntax, this is easy:

data Foo ... where
  {-# INLINE [1] Bar #-}
  Bar :: ...

For traditional syntax, I think it's probably best to pull the pragmas to the 
top:

{-# NOINLINE Quux #-}
data Baz ... = Quux ... | ...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Static data and RULES

[David Feuer]

Semantically, the proposed scheme is very nearly equivalent to breaking
*every* data constructor into a worker and a wrapper, and allowing INLINE
and NOINLINE pragmas on the wrappers. That would allow terms built only
from constructor workers and literals to be identified as they're
constructed in any stage and left alone by the simplifier. It would also
allow people using RULES that match on constructors to make those work
reliably, by making sure the bindings they match on don't inline away or
get marked static too early. Of course, we don't actually need to add more
worker/wrapper pairs to do this; we can fake that.

On Feb 16, 2017 6:53 PM, "Simon Peyton Jones"  wrote:

> I’m sorry I still don’t understand the problem.  Can you give an example?
> It all works fine today; what will change in the proposed new scheme.
> Indeed what IS the proposed new scheme?
>
>
>
> I’m lost
>
>
>
> Simon
>
>
>
> *From:* David Feuer [mailto:david.fe...@gmail.com]
> *Sent:* 16 February 2017 23:51
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs ; Reid Barton ;
> Ben Gamari 
> *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
> 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
> altogether in simplification. Suppose we have
>
>
>
> foo = Just (Right [1])
>
>
>
> Then no amount of optimization will ever be useful. But what about RULES?
> If the outermost pattern in a rule matches on a data constructor, then it's
> not static anymore! We may be replacing it with something else. So we need
> a finer mechanism. We *also* need a finer mechanism for strict constructors
> in general. We need to avoid inlining those too early if they're mentioned
> in any position in RULES. Trying to make this work right automagically
> looks a bit tricky in the face of orphan rules and such.
>
>
>
> On Feb 16, 2017 6:35 PM, "Simon Peyton Jones" 
> wrote:
>
> 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:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *David
> Feuer
> *Sent:* 16 February 2017 22:13
> *To:* Ben Gamari ; Reid Barton 
> *Cc:* ghc-devs 
> *Subject:* Static data and RULES
>
>
>
> 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 constructors and it would be
> nice to let that keep happening. But on the other hand, RULES are
> apparently (according to Duncan Coutts) already broken for strict data
> constructors, because they have workers and wrappers.
>
>
>
> My thought: let's allow phased INLINE and NOINLINE pragmas for data
> constructors. The default would be INLINE. The ~ phase choice would not be
> available: once inline, always inline.
>
>
>
> Semantics
>
> ~~
>
>
>
> For all constructors:
>
>
>
> If a constructor is allowed by pragmas to inline in a certain phase, then
> in that phase terms built from it can be considered static. Once static,
> always static.
>
>
>
> If a constructor is not allowed to inline in a certain phase, terms built
> from it will be considered non-static.
>
>
>
> After demand analysis and worker/wrapper, all constructors are considered
> inline.
>
>
>
> For strict constructors:
>
>
>
> A strict constructor wrapper prohibited from inlining in a certain phase
> simply will not.
>
>
>
> 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.
>
>
>
> Syntax:
>
>
>
> For GADT syntax, this is easy:
>
>
>
> data Foo ... where
>
>   {-# INLINE [1] Bar #-}
>
>   Bar :: ...
>
>
>
> For traditional syntax, I think it's probably best to pull the pragmas to
> the top:
>
>
>
> {-# NOINLINE Quux #-}
>
> data Baz ... = Quux ... | ...
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Static data and RULES

[David Feuer]

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 wrapper could very well
inline before the rule has a chance to fire. We'd like to be able to phase
that inline to give it a chance.

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.

On Feb 16, 2017 7:08 PM, "David Feuer"  wrote:

> Semantically, the proposed scheme is very nearly equivalent to breaking
> *every* data constructor into a worker and a wrapper, and allowing INLINE
> and NOINLINE pragmas on the wrappers. That would allow terms built only
> from constructor workers and literals to be identified as they're
> constructed in any stage and left alone by the simplifier. It would also
> allow people using RULES that match on constructors to make those work
> reliably, by making sure the bindings they match on don't inline away or
> get marked static too early. Of course, we don't actually need to add more
> worker/wrapper pairs to do this; we can fake that.
>
> On Feb 16, 2017 6:53 PM, "Simon Peyton Jones" 
> wrote:
>
>> I’m sorry I still don’t understand the problem.  Can you give an
>> example?  It all works fine today; what will change in the proposed new
>> scheme.  Indeed what IS the proposed new scheme?
>>
>>
>>
>> I’m lost
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* David Feuer [mailto:david.fe...@gmail.com]
>> *Sent:* 16 February 2017 23:51
>> *To:* Simon Peyton Jones 
>> *Cc:* ghc-devs ; Reid Barton ;
>> Ben Gamari 
>> *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
>> 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
>> altogether in simplification. Suppose we have
>>
>>
>>
>> foo = Just (Right [1])
>>
>>
>>
>> Then no amount of optimization will ever be useful. But what about RULES?
>> If the outermost pattern in a rule matches on a data constructor, then it's
>> not static anymore! We may be replacing it with something else. So we need
>> a finer mechanism. We *also* need a finer mechanism for strict constructors
>> in general. We need to avoid inlining those too early if they're mentioned
>> in any position in RULES. Trying to make this work right automagically
>> looks a bit tricky in the face of orphan rules and such.
>>
>>
>>
>> On Feb 16, 2017 6:35 PM, "Simon Peyton Jones" 
>> wrote:
>>
>> 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:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *David
>> Feuer
>> *Sent:* 16 February 2017 22:13
>> *To:* Ben Gamari ; Reid Barton 
>> *Cc:* ghc-devs 
>> *Subject:* Static data and RULES
>>
>>
>>
>> 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 constructors and it would be
>> nice to let that keep happening. But on the other hand, RULES are
>> apparently (according to Duncan Coutts) already broken for strict data
>> constructors, because they have workers and wrappers.
>>
>>
>>
>> My thought: let's allow phased INLINE and NOINLINE pragmas for data
>> constructors. The default would be INLINE. The ~ phase choice would not be
>> available: once inline, always inline.
>>
>>
>>
>> Semantics
>>
>> ~~
>>
>>
>>
>> For all constructors:
>>
>>
>>
>> If a constructor is allowed by pragmas to inline in a certain phase, then
>> in that phase terms built from it can be considered static. Once static,
>> always static.
>>
>>
>>
>> If a constructor is not allowed to inline in a certain phase, terms built
>> from it will be considered non-static.
>>
>>
>>
>> After demand analysis and worker/wrapper, all constructors are considered
>> inline.
>>
>>
>>
>> For strict constructors:
>>
>>
>>
>> A strict constructor wrapper prohibited from inlining in a certain phase
>> simply will not.
>>
>>
>>
>> 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.
>>
>>
>>
>> Syntax:
>>
>>
>>
>> For GADT syntax, this is easy:
>>
>>
>>
>> data Foo ... where
>>
>>   {-# INLINE [1] Bar #-}
>>
>>   Bar :: ...

RE: Static data and RULES

[Simon Peyton Jones via ghc-devs]

The immediate problem today is with "S". The SCon wrapper could very well 
inline before the rule has a chance to fire. We'd like to be able to phase that 
inline to give it a chance.

Yes that’s a problem today.  It is orthogonal to the current thread.  (As I 
happens I have fix in my tree.)

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 fire?

I’m afraid I still do not understand what change is proposed, so I’m finding it 
difficult to see how to fix problems with it.

Simon


From: David Feuer [mailto:david.fe...@gmail.com]
Sent: 17 February 2017 00:30
To: Simon Peyton Jones 
Cc: ghc-devs ; Reid Barton ; Ben 
Gamari 
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 wrapper could very well 
inline before the rule has a chance to fire. We'd like to be able to phase that 
inline to give it a chance.

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.

On Feb 16, 2017 7:08 PM, "David Feuer" 
mailto:david.fe...@gmail.com>> wrote:
Semantically, the proposed scheme is very nearly equivalent to breaking *every* 
data constructor into a worker and a wrapper, and allowing INLINE and NOINLINE 
pragmas on the wrappers. That would allow terms built only from constructor 
workers and literals to be identified as they're constructed in any stage and 
left alone by the simplifier. It would also allow people using RULES that match 
on constructors to make those work reliably, by making sure the bindings they 
match on don't inline away or get marked static too early. Of course, we don't 
actually need to add more worker/wrapper pairs to do this; we can fake that.

On Feb 16, 2017 6:53 PM, "Simon Peyton Jones" 
mailto:simo...@microsoft.com>> wrote:
I’m sorry I still don’t understand the problem.  Can you give an example?  It 
all works fine today; what will change in the proposed new scheme.  Indeed what 
IS the proposed new scheme?

I’m lost

Simon

From: David Feuer [mailto:david.fe...@gmail.com]
Sent: 16 February 2017 23:51
To: Simon Peyton Jones mailto:simo...@microsoft.com>>
Cc: ghc-devs mailto:ghc-devs@haskell.org>>; Reid Barton 
mailto:rwbar...@gmail.com>>; Ben Gamari 
mailto: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 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 altogether in 
simplification. Suppose we have

foo = Just (Right [1])

Then no amount of optimization will ever be useful. But what about RULES? If 
the outermost pattern in a rule matches on a data constructor, then it's not 
static anymore! We may be replacing it with something else. So we need a finer 
mechanism. We *also* need a finer mechanism for strict constructors in general. 
We need to avoid inlining those too early if they're mentioned in any position 
in RULES. Trying to make this work right automagically looks a bit tricky in 
the face of orphan rules and such.

On Feb 16, 2017 6:35 PM, "Simon Peyton Jones" 
mailto:simo...@microsoft.com>> wrote:
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: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of David Feuer
Sent: 16 February 2017 22:13
To: Ben Gamari mailto:bgam...@gmail.com>>; Reid Barton 
mailto:rwbar...@gmail.com>>
Cc: ghc-devs mailto: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. 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 constructors and it would be nice 
to let that keep happening. But on the other hand, RULES are apparently 
(according to Duncan Coutts) already broken for strict data constructors, 
because they have workers and wrappers.

My thought: let's allow phased INLINE and NOINLINE pragmas for data 
constructors. The default would be INLINE. The ~ phase choice would not be 
available: once inline, always inline.

Semantics
~~

For all constructors:

If a constructor is 

Re: Static data and RULES

[David Feuer]

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 fire?
> 
> I’m afraid I still do not understand what change is proposed, so I’m finding
> it difficult to see how to fix problems with it.

I'm sorry; I wasn't trying to be obtuse; easy to drop context by mistake. The 
idea, at least roughly, is to have a "static" flag on each term. A term is 
considered static if it's

1. A Core literal,
2. A nullary constructor, or
3. A constructor whose arguments are all static.

Once a term is flagged static, the simplifier simply shouldn't try to optimize 
it--doing so is simply a waste of time.

The trouble is that rules like "L" can turn things that *look* utterly static 
into other things, through simplification that we then actually need! So we 
need to either try to figure out what's *really* static (which is complicated 
by orphan RULES) or we need to let users say so. I jumped for phased INLINE 
and NOINLINE pragmas because users are already accustomed to using those to 
say "I'm going to match on this with rules". It struck me also as a good way 
also to deal with the "S" rule that you've apparently found some other way 
around.

David
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC 8.2.1 status

[Ben Gamari]

Hello everyone,

It has been a bit over a week since the last update regarding 8.2.1. At
the moment we are on the final stretch leading up cutting the branch.
Over the last week I have been cleaning up a variety of odds and ends
around the tree, bumping core libraries, merging some last patches,
smoke testing, and putting the final touches on the Typeable branch
which will be merged shortly.

However, during testing against Hackage I found a regression (#13255)
due to the recent join-points merge that needs to be addressed before we
can consider cutting a release candidate. This will likely be resolved
soon, which should allow us to release a source release by mid-to-late
next week (assuming no further regressions are found).

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Static data and RULES

[Ben Gamari]

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, the "L" rule will never fire.
>  
>> Why doesn’t it fire?
>> 
>> I’m afraid I still do not understand what change is proposed, so I’m finding
>> it difficult to see how to fix problems with it.
>
> I'm sorry; I wasn't trying to be obtuse; easy to drop context by mistake. The 
> idea, at least roughly, is to have a "static" flag on each term. A term is 
> considered static if it's
>
> 1. A Core literal,
> 2. A nullary constructor, or
> 3. A constructor whose arguments are all static.
>
> Once a term is flagged static, the simplifier simply shouldn't try to 
> optimize 
> it--doing so is simply a waste of time.
>
For the record, David is referring to the proposal I briefly describe in
ticket #13282. I started on a patch implementing this idea earlier this
week, but eventually encountered enough tricky cases that I decided to
put it aside for now to focus on the 8.2 release. Moreover, I have a
sneaking suspicion Simon might be working along some similar threads.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs