#4874: Unnecessary reboxing when using INLINABLE
---------------------------------+------------------------------------------
Reporter: tibbe | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 7.0.3
Component: Compiler | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Changes (by tibbe):
* cc: johan.tib...@… (added)
Comment:
Background: While trying to give an efficient implementation of #4887,
I've run into what could be the same issue.
This is an entirely new test case, so it might shine more light on the
problem. To reproduce (using GHC 7.0.1):
{{{
tar zxf location.tar.gz
cd repro
ghc -O2 Test.hs -ddump-simpl
}}}
The interesting part is the series of calls to call site specialized
functions, starting at `Test.test`. In the attached Core, note how
`$wpoly_go_r1FO` returns an unboxed tuple, which is scrutinized by
`Test.$ssearch`. `Test.$ssearch` then converts the unboxed tuple to a
boxed tuple and returns it to `Test.test`, where it's scrutinized again. I
would expect `Test.$ssearch` to be inlined into `Test.test` (it's body is
trivial) and there to be now allocation of (boxed) tuples.
Here's the relevant part of the Core:
{{{
Test.$ssearch :: forall a. Int -> M.Map Int a -> (Maybe a, M.Location Int
a)
Test.$ssearch =
\ (@ a)
(k0 :: Int)
(m :: M.Map Int a) ->
case k0 of _ { I# k0# ->
case $wpoly_go_r1FO @ a k0# (M.Root @ Int @ a) m
of _ { (# ww2_s1Fy, ww3_s1Fz #) ->
(ww2_s1Fy, ww3_s1Fz)
}
}
Test.test :: M.Map Int Int -> M.Map Int Int
Test.test =
\ (m :: M.Map Int Int) ->
case Test.$ssearch @ Int Test.test2 m
of _ { (ds_d1DR, l) ->
case ds_d1DR of _ {
Nothing ->
M.assign @ Int @ Int Test.test1 l;
Just v ->
case v of _ { I# v# ->
M.assign
@ Int
@ Int
(I# (+# v# 1))
l
}
}
}
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4874#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
