add INLINEABLE to maybe, either, bool

[Dan Burton]

I'm wary of "let's not mark it as INLINE because we want the compiler to
automagically inline it for us." This seems like saying we should not have
type signatures, because we want the type inferencer to figure it out for
us. (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?)

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?

-- Dan Burton


On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Contrary to appearances, I fully agree. =)
>
>
> On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin at well-typed.com>wrote:
>
>> I'm strongly opposed to this.
>>
>> Being INLINE happy is not a good thing, it is a bad thing. More often
>> than not, I see people stuffing INLINE all over the place for things
>> that would trivially be unfolded and put in the interface file anyway.
>> This is bad, and it teaches people to just use the INLINE hammer
>> everywhere instead of understanding the actual implications of what
>> the inliner does. It also makes it impossible to actually observe how
>> the inliner behaves and see where it needs tuning: if we just mark
>> everything INLINE, we might as well not have it and make it
>> unconditional.
>>
>> There are some particular cases where GHC is hesitant to inline small
>> things if it would lead to work duplication, or where the inliner
>> behavior is tweaked and you may want to force it across multiple
>> versions to be sure (lens is a good example of this.) But this is far
>> more rare, and this case is not that. In particular, Joachim checked
>> the 'bool' commit. As expected, the unfolding for bool was put into
>> the interface file for Data.Bool, meaning if you use -O (or just -O0
>> -fno-ignore-interface-pragmas,) it should be inlined at call sites
>> appropriately when it is used.
>>
>> If we're going to INLINE things, we need to make sure it actually has
>> an empirical benefit, by looking at the core, and seeing where the
>> inliner is failing. Not just attach it to things because it seems like
>> a good idea. This also helps drive feedback into the inliner so we can
>> see where it fails.
>>
>> On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>> > Its come to my attention that maybe, either, and its new sibling bool,
>> all
>> > lack the
>> > INLINEABLE attribute, or its more aggressive sibling INLINE
>> >
>> > this seems like one of those operations where inlining in client use
>> sites
>> > is a good option to have, and currently not possible!
>> >
>> > theres probably other stuff that would benefit from an INLINEABLE
>> pragma in
>> > base,
>> > but this is an obvious, simple, "easy win" that I noticed when Oliver's
>> > patch got merged into base.
>> >
>> > Thoughts?
>> > Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>> >
>> > cheers
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> >
>>
>>
>>
>> --
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> 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/20130916/9b477b97/attachment.htm>