#5928: INLINABLE fails to specialize in presence of simple wrapper
---------------------------------+------------------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by tibbe):
Replying to [comment:3 simonpj]:
> > Manually marking `(!)` as `INLINABLE` works, but users shouldn't have
to do that.
>
> Why do you say that "users should not have to do that"? Why are you
happy to annotate `lookup` but not `(!)`?
I should first clarify what I meant by "user." It's fine for me, the
author of a high performance library, to have to understand the finer
details of GHC performance tuning, as long as that performance tuning can
be hidden inside the library.
Now, should a user ''of my library'' have to understand how I use
INLINABLE ''inside'' my library, or risk large performance degradations?
I'd hope not, because if users need to have the same level of
understanding as we who write these core libraries, everyone needs to be
an expert to use the language.
I suspect my choice of name for the wrapper, `(!)`, was a poor one, as it
made it seem that it was part of the library when it was intended to
represent a function defined outside the library. Here's what really
happend:
* In the unordered-containers library I defined `lookup`, but not `(!)`.
* Lennart, who was porting some code from the containers library to the
unordered-containers library, defined ''his'' own `(!)` function, in terms
of ''my'' `lookup` function.
* Lennart didn't put a INLINABLE pragma on ''his'' function, not knowing
that this was needed to not lose the effect of the INLINABLE pragma I put
on ''my'' `lookup` function.
* Things didn't specialize; performance was poor.
> Maybe your position is:
> * every overloaded function should be `INLINABLE`.
> If that was the rule then all overloading would be specialised, at the
cost of some code duplication. But it's not the rule at the moment. I
guess we could have a flag to give that behaviour -- but then you'd have
to remember to use it.
I don't think the lack of such a rule is the problem here. Look at this
core:
{{{
Test.test1 =
Data.HashMap.Base.lookup
@ GHC.Types.Int
@ GHC.Types.Int
GHC.Classes.$fEqInt
Data.Hashable.$fHashableInt
Test.test2
}}}
Why is `lookup` being passed two dictionaries when it's marked as
INLINABLE? This ought to have triggered a specialization.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5928#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
