<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">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"><u></u>
<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">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">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">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
</blockquote></div>