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, but when I asked Dunca
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
them,
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 th
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:
>
| 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:
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
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)
/tmp/ghctest-
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 tha
Simon Peyton Jones via ghc-devs writes:
> 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 stran
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 essentially linearly in the
numbe
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 exh
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 constructors
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 whethe
{-# 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.
14 matches
Mail list logo