Everyone: please take a look.
Luke
Very good.
· I think it’s fine to work from your repo; no need to use the main
repo.
· One big patch is fine. The exception is late lambda-lifting which
would best be done separately.
· Can you identify any bits that you are less h
Hello all! For your consideration, I present patch D2853: Join points.
https://phabricator.haskell.org/D2853
It validates* and it's ready for wider reviewing, so please help me get it to
land before the freeze!
It's ... sizable. There's not really any way to split it, since
c-devs
Subject: Join points
Hello all! For your consideration, I present patch D2853: Join points.
https://phabricator.haskell.org/D2853
It validates* and it's ready for wider reviewing, so please help me get it to
land before the freeze!
It's ... sizable. There's not really any w
Revised version of the join points patch is up:
https://phabricator.haskell.org/D2853
Hoping to commit ASAP. Thanks all!
- Luke Maurer
University of Oregon
maur...@cs.uoregon.edu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org
Luke Maurer writes:
> Revised version of the join points patch is up:
>
> https://phabricator.haskell.org/D2853
>
> Hoping to commit ASAP. Thanks all!
>
I have a few further review comments that I'm about to submit.
Cheers,
- Ben
signature.asc
Des
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Luke
| Maurer
| Sent: 31 January 2017 23:48
| To: ghc-devs
| Subject: Join points revised
|
| Revised version of the join points patch is up:
|
| https://phabricator.haskell.org/D2853
|
| Hoping to commit ASAP.
(e.g. -fvanishing-join-points) might
be helpful.
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
tion
under "New idea: use join points". Let's do it!
Ticket here: https://ghc.haskell.org/trac/ghc/ticket/13567
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Hi Simon,
Am Freitag, den 27.10.2017, 15:24 + schrieb g...@git.haskell.org:
> commit 128e4c1ffa29f3dfade7128152c143cd601aaa3a
> Author: Simon Peyton Jones
> Date: Fri Oct 27 16:20:24 2017 +0100
>
> Wip on floating join points
do you expect to merge that soon
rather difficult to see through the
> noise.
>
> This is actually perhaps another case where Simon Marlow suggestion of
> introducing a family of -v* flags (e.g. -fvanishing-join-points) might
> be helpful.
>
> Cheers,
>
> - Ben
>
> ___
Talkative Join points warning
|
|
| Hi Luke,
|
| I've noticed that a new WARN in OccurAnal seems to be quite loud.
| Validations now produce thousands of lines of the form,
|
| WARNING: file compiler/simplCore/OccurAnal.hs, line 2633
| OccurAnal failed to rediscover join poi
shouldn't!
S
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
| Gamari
| Sent: 02 February 2017 21:36
| To: Luke Maurer
| Cc: ghc-devs@haskell.org
| Subject: Talkative Join points warning
|
|
| Hi Luke,
|
| I've noticed that a new WARN
intern, mainly working on LLVM backend
stuff. But he knows a lot about CPS etc and he'd read our paper. In
talking about it, we realised a new Join Point Win!
I’ve written it up in
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Loopification
under “New idea: use join points”. Let
. In
> talking about it, we realised a new Join Point Win!
>
> I’ve written it up in
>
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Loopification
>
> under “New idea: use join points”. Let’s do it!
>
> Ticket here: https
Hi all,
I just came up with this, and unless I write it down I doubt I’ll be
able to fall asleep.
The problem I’m trying to solve is the bad interaction of the CPR worker
wrapper transformation and join points. Consider, as a running example:
f x =
let $j n = Just (Int# (n +# 1))
in case x of
Hi,
I created a first prototype of this optimization (branch
wip/common-context), and the results are a clear, although very small
win in some benchmarks, and no regression (ignoring the flaky
cacheprof):
Pro
ll.org] On Behalf Of
| Joachim Breitner
| Sent: 12 December 2013 01:29
| To: ghc-devs@haskell.org
| Subject: Common Context transformation for join points
|
| Hi all,
|
| I just came up with this, and unless I write it down I doubt I’ll be
| able to fall asleep.
|
| The problem I’m trying
Hi,
Am Dienstag, den 31.12.2013, 11:33 + schrieb Simon Peyton-Jones:
> Interesting. We can discuss when you get back, but let me jot down
> one comment. You write:
>
> | This will always happen if the join point function gets a richer
> | CPR property than the function that it belongs to
>
The below "Core" output from "ghc -O2" (9.2/8.10) for the attached
program shows seemingly rendundant join points:
join {
exit :: State# RealWorld -> (# State# RealWorld, () #)
exit (ipv :: State# RealWorld) = jump $s$j ipv } in
join {
s not have to be true (lambdas)
3. Join-points are implemented using LNE bindings and I can imagine a
join-points not having any
parameters (and not being a lambda).
Three points above seem inconsistent - where does my reasoning go wrong? I
suspect that the Note
might be wrong and an upda
ssion from 8.0.2.
However, I make a mailing list post as I unsure how to expect the
inliner to treat join points.
Questions.
1. Does the inliner treat join point bindings differently to normal bindings?
2. How can I stop the compiler introducing this join point which seems
to get in the way o
If I understand correctly, the LNE-detection in CoreToSTG makes all of the
decisions; it's the only place that the StgLetNoEscape constructor arises.
Join-points are only implemented as LNE if they are detected to be LNE,
which they most often — but not always! — after all the core
gt; 1. Note [What is a non-escaping let] says that one of conditions of
> > binding being a non-escaping
> > let is non-updatability.
> > 2. My understanding is that a if a binding has at least one parameter it
> > is non-updatable, though
> > I suspect that converse
table, though
I suspect that converse does not have to be true (lambdas)
3. Join-points are implemented using LNE bindings and I can imagine a
join-points not having any
parameters (and not being a lambda).
A join-point always has at least one argument. If there are no
arguments, then a dummy o
-boun...@haskell.org] On Behalf Of Simon
| Marlow
| Sent: 17 October 2013 09:44
| To: Jan Stolarek; ghc-devs@haskell.org
| Subject: Re: Non-escaping lets, join-points and binding updatability
|
| On 16/10/2013 18:27, Jan Stolarek wrote:
| > Hi all,
| >
| > I'm trying to understand this:
| >
Of Simon
> | Marlow
> | Sent: 17 October 2013 09:44
> | To: Jan Stolarek; ghc-devs@haskell.org
> | Subject: Re: Non-escaping lets, join-points and binding updatability
> |
> | On 16/10/2013 18:27, Jan Stolarek wrote:
> | > Hi all,
> | >
> | > I'm t
[ Sorry wrong version of attachment in previous message. ]
The below "Core" output from "ghc -O2" (9.2/8.10) for the attached
program shows seemingly rendundant join points:
join {
exit :: State# RealWorld -> (# State# RealWorld, () #)
exit (ipv :: S
There is absolutely no reason not to common-up those to join points. But we
can't common up some join points when we could if they were let's. Consider
join j1 x = x+1
in case v of
A -> f (join j2 x = x+1 in ...j2...)
B -> j1...
C -> j1...
Even tho
On Sat, Nov 20, 2021 at 09:15:15PM +, Simon Peyton Jones via ghc-devs wrote:
> GHC.Core.Opt.CSE is conservative at the moment, and never CSE's *any*
> join point. It would not be hard to make it clever enough to CSE join
> points, but no one has yet done it.
>
> Do open
In this example: why would it stop being a join point ?
Admittedly, my intuition might be skewed by my own ideas about how join
points are sortah a semantic special case of other constructs.
On Sat, Nov 20, 2021 at 4:17 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
&
On Sun, Nov 21, 2021 at 06:53:53AM -0500, Carter Schonwald wrote:
> On Sat, Nov 20, 2021 at 4:17 PM Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> > There is absolutely no reason not to common-up those to join points. But
> > we can't co
| For two join points to be duplicates they need to not only be alpha
| equivalent but to also have the same continuation.
Yes exactly. And it would not be hard to adapt the existing CSE pass to support
this. Just needs doing.
A ticket and a repo case would be really helpful.
Simon
PS: I
On Wed, Nov 24, 2021 at 11:14:00PM +, Simon Peyton Jones via ghc-devs wrote:
> | For two join points to be duplicates they need to not only be alpha
> | equivalent but to also have the same continuation.
>
> Yes exactly. And it would not be hard to adapt the existing CSE pass
esult valid acc (ptr `minusPtr` start)
become respectively (ipv2 and w3 are IO state tokens):
1. jump exit2 ww4 ww5 valid ipv2
-- acc ptr valid s#
2. jump exit3 ww4 ww5 w3 valid
-- acc ptr s# valid
So the join points are then only alpha equi
GHC developers
| Subject: Are join points inlined differently from normal bindings?
|
| I have quite a complicated program which relies on the optimiser inlining
| very aggressively.
|
| In 8.0.2, it works fine and produces the core I am expecting.
|
| In 8.2.2, one of the bindings is identified
Hello Victor,
generally GHC does try to common up join points and duplicate
expressions like that.
But since that's relatively expensive most of the duplication happens
during the core-cse pass which only happens once.
We don't create them because they are harmless. They are sim
On Sat, Nov 20, 2021 at 12:49:08PM +0100, Andreas Klebinger wrote:
> For the assembly I opened a ticket:
> https://gitlab.haskell.org/ghc/ghc/-/issues/20714
Thanks, much appreciated. Understood re redundant join points, though
in the non-toy context the redundnat point code is noticeably
On Sat, Nov 20, 2021 at 01:54:36PM -0500, Viktor Dukhovni wrote:
> Is there some way for GHC to figure out to not float out such cheap
> computations? The 'Result' constructor is strict, so there's no cost to
> evaluating `used > 0`, and cloning the entire computation is I think
> the more unfort
d a ticket:
https://gitlab.haskell.org/ghc/ghc/-/issues/20714
Thanks, much appreciated. Understood re redundant join points, though
in the non-toy context the redundnat point code is noticeably larger.
join {
exit4
:: Addr# -> Word# ->
39 matches
Mail list logo
