#3116: missed opportunity for call-pattern specialisation
-----------------------------------------+----------------------------------
Reporter: duncan | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.10.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-----------------------------------------+----------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
As luck would have it, I had a spare hour and looked at this. I was happy
to discover that a few months ago I'd changed the representation of a
`StrictArg` continuation (the `SimplCont` type) that made it easy to
achieve what you want; previously it was nigh impossible which is why GHC
was so wimpy.
So a matter of half a dozen lines of code changed gives the result you
want. I attach my standalone test case; try compiling it with GHC 6.10 to
see the bad behaviour. But with my new patch we get this for `length`:
{{{
T3116.$s$wgo =
\ (sc_sy6 :: T3116.ByteString)
(sc1_sy7 :: GHC.Prim.Int#)
(sc2_sy8 :: GHC.Prim.Int#)
(sc3_sy9 :: GHC.ForeignPtr.ForeignPtrContents)
(sc4_sya :: GHC.Prim.Addr#)
(sc5_syb :: GHC.Prim.Int#) ->
case sc1_sy7 of ds_XvF {
__DEFAULT ->
T3116.$s$wgo
sc_sy6
(GHC.Prim.-# ds_XvF 1)
(GHC.Prim.+# sc2_sy8 1)
sc3_sy9
sc4_sya
(GHC.Prim.+# sc5_syb 1);
1 -> T3116.$wgo (GHC.Prim.+# sc5_syb 1) sc_sy6
}
T3116.$wgo =
\ (ww_sxF :: GHC.Prim.Int#) (w_sxH :: T3116.ByteString) ->
case w_sxH of _ {
T3116.Empty -> ww_sxF;
T3116.Chunk ipv_sw9 ipv1_swa ipv2_swb ipv3_swc ipv4_swd ->
case ipv3_swc of ds_XvF {
__DEFAULT ->
T3116.$s$wgo
ipv4_swd
(GHC.Prim.-# ds_XvF 1)
(GHC.Prim.+# ipv2_swb 1)
ipv1_swa
ipv_sw9
(GHC.Prim.+# ww_sxF 1);
1 -> T3116.$wgo (GHC.Prim.+# ww_sxF 1) ipv4_swd
}
}
end Rec }
T3116.length :: T3116.ByteString -> GHC.Types.Int
T3116.length =
\ (w_sxH :: T3116.ByteString) ->
case T3116.$wgo 0 w_sxH of ww_sxK { __DEFAULT ->
GHC.Types.I# ww_sxK
}
}}}
Can't do much better than that. Expect a patch shortly.
I don't understand your recent comment above, though. The RULES generated
from the specialisations are indeed applied in the original function! Can
you give a standalone example showing what happens, and what you want to
happen instead?
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3116#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
