<div dir="ltr"><div>Yes, this has been on my todo for a long time :)</div><div>Essentially all inlinings/rules in binary should be gone through and confirmed whether they're still needed.</div><div>I had a look now to get some insight.</div><div><br></div><div>Since a few versions GHC warns in this way when something might not go the way it was intended, a great way to learn more about how inlining and rules work and to avoid surprises.</div><div>All these warnings are proof of my poor understanding when I implemented it. Naturally it should all be fixed.</div><div><br></div><div>Here's how I reasoned when implementing it;</div><div>In Data.Binary.Get we have functions we always want to inline, even if GHC doesn't think it's a good idea. Therefore there are both INLINE pragmas as well as RULES to achieve this. GHC now warns that the function might get inlined before the rule triggers, which is ok since they do the same thing.</div><div>We should probably re-evaluate whether always inlining still is a good idea. If it is, we can keep the RULES to inline, and change the INLINE to NOINLINE and let the RULES do their job.</div><div><br></div><div>In Data.Binary.Internal.Get we attempt a trick where applicative code can become more efficient. It tries to rewrite the components of an expression "f <*> g <*> h" into something that does f, g and h with a single bounds check (the check for "do we have enough input bytes to continue?").</div><div>This trick relies so much on that the user's code has been inlined properly that it probably very rarely fires in a real application. It does wonders in the unrealistic micro benchmark, though :)</div><div>Probably those rules can be removed without any real code suffering. I'd like to add some more real world benchmarks, and finally test with the changes proposed above. </div><div><br></div><div>Lennart</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-24 13:44 GMT+02:00 Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-GB" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Lennart<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">In the binary library I’m seeing lots of these warnings:<u></u><u></u></span></p>
<p>libraries/binary/src/Data/Binary/Get.hs:420:1: warning:<u></u><u></u></p>
<p>    Rule "getWord16le/readN" may never fire<u></u><u></u></p>
<p>      because ‘getWord16le’ might inline first<u></u><u></u></p>
<p>    Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning:<u></u><u></u></p>
<p>    Rule "flush/flush" may never fire<u></u><u></u></p>
<p>      because ‘flush’ might inline first<u></u><u></u></p>
<p>    Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:12.0pt">The warnings look right to me: currently everything is very fragile and may not work as you intend.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">You may want to look into this?<span class="HOEnZb"><font color="#888888"><u></u><u></u></font></span></span></p><span class="HOEnZb"><font color="#888888">
<p class="MsoNormal"><span style="font-size:12.0pt">Simon<u></u><u></u></span></p>
</font></span></div>
</div>

</blockquote></div><br></div></div></div>