add INLINEABLE to maybe, either, bool

Simon Peyton-Jones simonpj at microsoft.com
Tue Sep 17 19:45:32 CEST 2013


Johan

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.

What other behaviour did you seek?

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<mailto: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<mailto: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<mailto:Libraries at haskell.org>
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto: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/20130917/3b4463e3/attachment.htm>


More information about the Libraries mailing list