add INLINEABLE to maybe, either, bool

[Johan Tibell]

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
>
>