add INLINEABLE to maybe, either, bool

[Simon Peyton-Jones]

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