add INLINEABLE to maybe, either, bool

[Johan Tibell]

http://ghc.haskell.org/trac/ghc/ticket/5928

On Tue, Sep 17, 2013 at 10:56 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> Ah I see, thanks!  That's a bug.  Would you like to make a ticket for it?  Or is there one already?
>
> Simon
>
> |  -----Original Message-----
> |  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Johan Tibell
> |  Sent: 17 September 2013 18:50
> |  To: Simon Peyton-Jones
> |  Cc: Haskell Libraries
> |  Subject: Re: add INLINEABLE to maybe, either, bool
> |
> |  On Tue, Sep 17, 2013 at 10:45 AM, Simon Peyton-Jones
> |  <simonpj at microsoft.com> wrote:
> |  > I don't understand your difficulty below at all.  After all, at every call site of 'f'
> |  we will inline it, as the INLINE pragma stipulates; and then we'll generate
> |  specialised code for g, exactly as (I suppose) you hope.
> |
> |  We don't! This is an actual bug I had in unordered-containers and it's
> |  fixes by changing the INLINE to INLINABLE on f above. I think the
> |  problem is that once we're done inlining, the specilize phase has
> |  already passed (i.e. specialize happens before the simplifier). If you
> |  remember we once discussed trying to add a second, late specialize
> |  phase to cover this very case.
> |
> |  > What other behaviour did you seek?
> |
> |  At the call site of f (where f gets inlined) should get the Hashable
> |  dict specialized if the concrete type of 'a' is known.
> |
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Johan Tibell
> |  > Sent: 17 September 2013 18:41
> |  > To: Dan Burton
> |  > Cc: Haskell Libraries
> |  > Subject: Re: add INLINEABLE to maybe, either, bool
> |  >
> |  >
> |  >
> |  > Aside: INLINE pragmas do more than INLINE nowadays, they prevent the RHS
> |  (to be inlined) from being optimized before inlining happens. This makes it
> |  interfere badly with INLINABLE. For example, if you have:
> |  >
> |  >
> |  >
> |  > f = g
> |  >
> |  > {-# INLINE f #-}
> |  >
> |  >
> |  >
> |  > g :: Hashable a => ...
> |  > g = ...
> |  >
> |  > {-# INLINABLE g #-}
> |  >
> |  >
> |  >
> |  > INLINE makes the call site specialization that INLINABLE otherwise gives fail.
> |  >
> |  >
> |  >
> |  > I for one miss the old INLINE.
> |  >
> |  >
> |  >
> |  > On Tue, Sep 17, 2013 at 10:27 AM, Dan Burton <danburton.email at gmail.com>
> |  wrote:
> |  >
> |  > I again want to emphasize how we can view INLINE annotations much the same
> |  way as type annotations. It is considered good practice to annotate top-level
> |  definitions with type signatures. Why? Is it because the compiler can't figure it
> |  out? Is it because the programmer doesn't trust the compiler to figure it out? No,
> |  it's because it is a visible, enforced sanity check to make sure that the
> |  programmer and the compiler are on the same page, regardless of any magic the
> |  compiler is capable of. (I like the various ideas that are being thrown around about
> |  "asserting" that something will be inlined.)
> |  >
> |  >
> |  >
> |  > I see superfluous INLINE pragmas as for the benefit of humans, allowing them
> |  to express their desires explicitly, rather than relying on implicit behavior that is
> |  hard for the average muggle to understand, verify, or guarantee. If someone reads
> |  through the source, and wonders whether "bool" will be inlined, they don't need to
> |  know any details about the current state of the inliner algorithm when they can
> |  just see the pragma right there in the source.
> |  >
> |  >
> |  >
> |  > The inliner should be at the whim of its masters, the humans, not the other way
> |  around.
> |  >
> |  >
> |  >
> |  >
> |  > -- Dan Burton
> |  >
> |  >
> |  >
> |  > On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma at ro-che.info>
> |  wrote:
> |  >
> |  > Austin,
> |  >
> |  > First of all, let me say that I am generally on the same side of this
> |  > argument as you are now.
> |  >
> |  > But Dan raised very good and valid points, and I don't think you
> |  > addressed them directly (quotations follow):
> |  >
> |  > 1. If you want to test the auto-inliner's wisdom, then just add a
> |  >
> |  >    setting that ignores INLINE pragmas and see if it inlines the same
> |  >    thing that humans do?
> |  >
> |  > 2. I don't really care how it's accomplished, but I do think that we should
> |  >
> |  >    make sure that maybe, either, and bool are inlined, and the most obvious
> |  >    way to accomplish this is to directly mark them INLINE, is it not?
> |  >
> |  > Roman
> |  >
> |  > _______________________________________________
> |  > Libraries mailing list
> |  > Libraries at haskell.org
> |  > http://www.haskell.org/mailman/listinfo/libraries
> |  >
> |  >
> |  >
> |  >
> |  > _______________________________________________
> |  > Libraries mailing list
> |  > Libraries at haskell.org
> |  > http://www.haskell.org/mailman/listinfo/libraries
> |  >
> |  >
> |  _______________________________________________
> |  Libraries mailing list
> |  Libraries at haskell.org
> |  http://www.haskell.org/mailman/listinfo/libraries