add INLINEABLE to maybe, either, bool

[Edward Kmett]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130916/4c7c7448/attachment.htm>