Re: Static data and RULES

I also remember using such rules in my code. See for example: https://github.com/basvandijk/aeson/blob/json-builder/Data/Aeson/Types/Internal.hs#L273 TIL rules like that are fragile. Bas Op 17 feb. 2017 3:49 p.m. schreef "David Feuer" : I've never used such rules myself,

RE: Early inline

I can see that - it'd be nice to associate the perf improvements with the right patch - it'd be nice to associate the error-message wibbles with the right patch - it'd be nice to Phab them all so others can comment But life is short, so I'd be perfectly happy if we were able to just commit

Re: Early inline

Hi, Am Freitag, den 17.02.2017, 16:41 + schrieb Simon Peyton Jones via ghc-devs: > · I have not sweated through which patch is responsible for > which perf improvments.  Maybe Gipeda can tell? yes it can! It does not draw nice graphs for branches yet, but it will (try to) build all

Re: Early inline

Yes, we definely want these. Are you wanting each of these submitted as a separate differential *in order*? Or do you want a more complex mix-and-match? Also, are there any commits you think should be squashed? On Friday, February 17, 2017 4:41:33 PM EST Simon Peyton Jones via ghc-devs wrote:

RE: Early inline

| Yay! Is that related to the following ("I also want to investigate making | INLINE pragmas fire in the "gentle" phase, on the grounds that that's | what the programmer said.")? | Yes, precisely Simon | -Original Message- | From: Mikolaj Konarski [mailto:miko...@well-typed.com] | Sent:

Re: Early inline

Yay! Is that related to the following ("I also want to investigate making INLINE pragmas fire in the "gentle" phase, on the grounds that that's what the programmer said.")? https://ghc.haskell.org/trac/ghc/ticket/12603#comment:30 On Fri, Feb 17, 2017 at 5:41 PM, Simon Peyton Jones via ghc-devs

RE: Trac #13255

I've just rebuilt that branch from scratch. I see Unexpected failures: /tmp/ghctest-q4hnbi/test spaces/./codeGen/should_run/cgrun057.run cgrun057 [bad stderr] (profasm) /tmp/ghctest-q4hnbi/test spaces/./profiling/should_run/T2592.run T2592 [bad stderr] (profasm)

Early inline

Ben, David, Reid I have been working for months (on and off, mostly off, but very ON for the last week or two) on a very simple idea: the simplifier should inline things even in the "gentle" phase. It seems so simple. And it is: the key patch is tiny. But it stressed corners of the optimiser

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

Trac #13255

Ben I have pushed a fix for #13255 (blocking the release) to wip/T13255-spj It contains a series of patches, of which the important one is the last. But Phabbing them exceeded my skill level. I'm rebuilding yet again, but I got a couple of strange testsuite errors. Here is one T2592: Heap

Re: Static data and RULES

I've never used such rules myself, but when I asked Duncan Coutts about whether and how such rules were used in the wild, he said > Well I've certainly tried to use that in the past. > A previous version of the cbor lib which used a different > representation did a lot of matching on

RE: Static data and RULES

PS: before we go to some effort to optimise X, can we · do some measurements to ensure that X is a problem · check that the problem with X doesn’t have an easy solution For example: · Make a big file with lots of static data · Compile it · Check

RE: Static data and RULES

{-# RULES "L" LCon1 0 = LCon2 Oh I missed this entirely. You want to write a rule FOR a data constructor I thought you just meant one that matches on a data constructor. That is you want (L 0) to rewrite, all by itself, to LCon2? That had never occurred to me as a possibility. Bizarre.