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,

GHC 8.2.1 status

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,

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

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

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

RE: Static data and RULES

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

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: Better perf for haddock.base, haddock.Cabal (f4aa998)

| 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

Re: Static data and RULES

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

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

Re: DR workflows

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

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

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

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

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

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

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