<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>> But then we'll add cost centres to data constructor workers
and wrappers. ... but have the "add cost centre" pass skip over
data constructor workers and wrappers.<br>
<br>
We already do this. See
compiler/GHC/Core/LateCC/TopLevelBinds.hs:112 where we already
check for constructor bindings.<br>
I've added this to avoid adding ccs to workers but it should work
for wrappers just the same.<br>
<br>
That means I think your plan A should work fine, assuming there is
no need to tidy those binds.<br>
<br>
> I'm a bit inclined to combine the late-cc/materialise/prep
combo into the main function of GHC.CoreToStg.Prep.<br>
<br>
In general I always found it easier to understand passes when they
are narrow in scope. <br>
Sometimes combining them is worth it for performance reasons but I
suspect this is not so here.</p>
<p>And their concerns are clearly separate so combining them seems
odd to me from code structure point of view as well. <br>
<br>
For example LateCC must return a list of inserted cost centres,
while CorePrep doesn't need to care about such a thing at all
currently!<br>
<br>
So I would rather keep those clearly separated. <br>
<br>
> I was thinking that the class-op selector is a small, cheap
function, so I don't mind not profiling it. But perhaps your point
is that calling it symptomatic of running overloaded code, and we
might want to know that.<br>
<br>
It has definitely been a helpful indicator that optimizations went
wrong for me in the past, as one wouldn't expect (>>=) or
similar to be called 5 million times in a optimized program.<br>
</p>
<p>Beyond that one of the ideas behind the current late cost centre
profiling is that it can tell you with fairly high precision which
(top level) functions are actually executed at runtime.<br>
Removing method selectors muddies the water there a bit.<br>
</p>
<p></p>
<div class="moz-cite-prefix">Am 07/04/2025 um 13:37 schrieb Simon
Peyton Jones:<br>
</div>
<blockquote type="cite"
cite="mid:CAJKmMz-tcNcL+n9Pu=BTJ-n-q3NY5fEibuaOOZpVr3q3LxE0KQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<blockquote class="gmail_default gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you are sure there is no need to tidy the class method
selectors then it would be clearest to have a explicit
"materializeImplicitBinds" step in the pipeline after tidy and
before lateCC runs.
<br>
</blockquote>
<div><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">Yes,
I want to put all the materialisation in one place. I think
you are suggesting Plan A</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">
<ul>
<li>Tidy</li>
<li>Materialise implicit bindings (class op selectors, data
constructor workers, data constructor wrappers)</li>
<li>Add late cost centres</li>
<li>Run late plugins</li>
<li>Prep</li>
<li>CoreToStg</li>
</ul>
<div>But then we'll add cost centres to data constructor
workers and wrappers.</div>
<div><br>
</div>
<div>Or Plan B</div>
<div>
<ul>
<li>Tidy</li>
<li>Add late cost centres</li>
<li>Materialise implicit bindings (class op selectors,
data constructor workers, data constructor wrappers</li>
<li>Run late plugins</li>
<li>Prep</li>
<li>CoreToStg</li>
</ul>
Now we won't get cost centres on class-op selectors, which
Matthew says he wants.</div>
<div><br>
</div>
<div>I suppose we could have do Plan A, but have the "add cost
centre" pass skip over data constructor workers and
wrappers.</div>
<div><br>
</div>
Do you have any views?</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">I'm
a bit inclined to combine the late-cc/materialise/prep combo
into the main function of GHC.CoreToStg.Prep. But I wonder
if the "late plugins" need to see (a) the materialised
implicit bindings and (b) late cost centres. I have no idea
how late plugins are used.</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">Matthew
asks</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"
class="gmail_default gmail_quote">
I would quite like to know if there is an unoptimised call to
>>= in my program. You have probably thought about this
a little, so interested to hear your opinion. <br>
</blockquote>
<div><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">I
was thinking that the class-op selector is a small, cheap
function, so I don't mind not profiling it. But perhaps your
point is that calling it symptomatic of running overloaded
code, and we might want to know that.</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">Simon
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, 7 Apr 2025 at 10:37,
Andreas Klebinger <<a
href="mailto:klebinger.andreas@gmx.at"
moz-do-not-send="true" class="moz-txt-link-freetext">klebinger.andreas@gmx.at</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>A interesting wrinkle! <br>
<br>
I agree with matt that having class methods show up in the
profile can be very helpful at times.<br>
<br>
Constructors and their wrappers on the other hand should
be of no concern.<br>
We explicitly try to avoid wrapping them in cost centres
as they generally add no useful information to profiles.<br>
<br>
I've briefly looked over the code and adding class methods
seems to be the *first* thing tidy does, not at it's end.
(in tidyProgram)<br>
That would suggest to me that there is a need to tidy
these implicit bindings so moving them might have further
unintended consequences.<br>
<br>
But then <span style="color:rgb(106,153,85)">Note
[Injecting implicit bindings]</span> claims we do it at
the end of tidy, but seems outdated.<span
style="color:rgb(106,153,85)"> </span>This seems like a
proper mess.<br>
</p>
<p>If you are sure there is no need to tidy the class method
selectors then it would be clearest to have a explicit
"materializeImplicitBinds" step in the pipeline after tidy
and before lateCC runs.<br>
That seems like it would be clearer and more coherent
overall. And it would sidestep this issue completely. <br>
<br>
Cheers<br>
Andreas<br>
<br>
</p>
<p><br>
</p>
<div>Am 07/04/2025 um 11:08 schrieb Matthew Pickering:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Simon,</div>
<div><br>
</div>
<div>It does seem strange (at first glance) that these
implicit things happen in two different places. <br>
</div>
<div><br>
</div>
<div>
<div>However, I think you should do this refactoring
in a separate MR to !10479, it seems unrelated to
the purpose of that patch and affects other things
like you have mentioned.</div>
<br>
</div>
<div>Why do you think the change in callstack is fine?
It seems the difference is `callstack001` is whether
there an entry for `>>=` or not, which seems
like quite an important thing to place a cost centre
on? Andreas has a</div>
<div>better intuition for this than me. I would quite
like to know if there is an unoptimised call to
>>= in my program. You have probably thought
about this a little, so interested to hear your
opinion. <br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Matt</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Apr 4, 2025 at
10:44 PM Simon Peyton Jones <<a
href="mailto:simon.peytonjones@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">simon.peytonjones@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Hi Matthew,
Andreas, Ben</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">In GHC today
there is a strange inconsistency:</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">
<ul>
<li>Bindings for data constructor wrappers and
class method selectors are added at the end of
CoreTidy.</li>
<li>Bindings for data constructor workers are
added at the start of CorePrep</li>
</ul>
<div>This is deeply strange. In !<a
href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479"
target="_blank" moz-do-not-send="true">10479
(unary class patch)</a> I had to make some
changes in this area and after being baffled I
moved all these implicit bindings to one place
at the start of CorePrep. That is simpler and
neater. There is no reason for them to be
separate.</div>
<div><br>
</div>
<div>BUT I find that one thing happens between
Tidy and Prep, namely late-cost-centre
injection. That means we will no longer get
late-cost-centres for data constructor wrappers
and class method selectors. I think that this
is what is causing diffs in the output for
callstack001 and friends in !10479.</div>
<div><br>
</div>
<div>I think that this is perfectly fine, and I
propose to accept the changes. <br>
</div>
<div><br>
</div>
<div>Another alternative would be to inject all of
these bindings at the end of Tidy (instead of
the start of Prep), But it's much nicer at the
start of Prep -- we don't want any of these
bindings to appear in interface files.</div>
<div><br>
</div>
<div>Can you confirm that the change is ok?
Thanks</div>
<div><br>
</div>
<div>Simon</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>