[GHC] #14152: Float exit paths out of recursive functions
GHC
ghc-devs at haskell.org
Mon Oct 30 17:38:21 UTC 2017
#14152: Float exit paths out of recursive functions
-------------------------------------+-------------------------------------
Reporter: nomeata | Owner: (none)
Type: task | Status: patch
Priority: normal | Milestone:
Component: Compiler | Version: 8.2.1
Resolution: | Keywords: JoinPoints
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: #14137 #10918 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by nomeata):
Replying to [comment:29 simonpj]:
> > I left it out for now, because instruction counts increase
>
> So, just to be sure: allocation counts did not change?
Nope. Byte-for-byte identical.
> > What I do, how ever, see is exit join points that are called from two
positions in the code, where inlining duplicates the code.
>
> What if you inline only join points that are called once? So that no
code duplication is involved.
I doubt that the code duplication is the real culprit here. More likely
things like different order of blocks leading to different decision later
in the code generation, e.g. in the register allocator, leading to less or
more register pressure and different registers being saved? Do you know
the difference between `stg_gc_noregs()` and `stg_gc_unpt_r1(R1)`?
> I'm having a hard time seeing why that should do anything bad. And it
can do something good... if you have
> {{{
> join j x = ...y...
> in
> ...jump j v...
> }}}
> then `y` will get pushed onto the stack at the `join`, so that its RHS
knows where to find it. If it's inlined that may not happen. So may be
more than just eliminating a jump.
Well, according to the numbers it's not happening.
Remember that the `jump` to an exit point is almost always going to the
right-hand-side of a case alternative. Which is, as far I as I can tell,
already a jump target, so the `y` in your example would have to be pushed
on the stack just the same, woudn’t it?
I understand that this is all a bit unsatisfying intellectually, but I
don’t want to sink more time into this, at least not without concrete
examples or other evidence that show that what we are doing now is indeed
bad.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14152#comment:30>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list