Hi Simon, It does seem strange (at first glance) that these implicit things happen in two different places. 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. 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 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. Cheers, Matt On Fri, Apr 4, 2025 at 10:44 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Hi Matthew, Andreas, Ben
In GHC today there is a strange inconsistency:
- Bindings for data constructor wrappers and class method selectors are added at the end of CoreTidy. - Bindings for data constructor workers are added at the start of CorePrep
This is deeply strange. In !10479 (unary class patch) https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479 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.
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.
I think that this is perfectly fine, and I propose to accept the changes.
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.
Can you confirm that the change is ok? Thanks
Simon