#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?
What I do, how ever, see is exit join points that are called from two
Nope. Byte-for-byte identical. 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