add INLINEABLE to maybe, either, bool

[Johan Tibell]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131011/fff88e7a/attachment.html>