Re: add INLINEABLE to maybe, either, bool

http://ghc.haskell.org/trac/ghc/ticket/5928 On Tue, Sep 17, 2013 at 10:56 AM, Simon Peyton-Jones 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@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 | 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@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 | 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 | 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@haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | > | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries@haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | > | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries