<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Thanks very much for this reply, Joachim. I see that `-fno-do-lambda-eta-expansion` with my example prevents moving the computation under the lambda where it gets repeatedly evaluated. I don't understand what this code motion/substitution has to do with eta-expansion. Is it that the `let` expression itself is eta-expanded? The GHC Users Guide describes this flag as "eta-expand let-bindings to increase their arity", which doesn't seem to fit here, since the `let`-bindings are not function-valued (though the `let` expression is).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks also for the suggestion of using `-dverbose-core2core` to see where the unwanted substitution happened.</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Did you measure whether this really is a problem? The benefits of not<br>dealing with dynamically allocated functions might outweigh the cost of<br>recalculating sin.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">No, I haven't measured. In this case, I'm compiling Haskell to GLSL for execution on a GPU, where the inner lambda will be over space, which means at least one application per pixel, so the computations moved under the inner lambda will be redundantly computed a few millions of times per frame (and much more with anti-aliasing). Instead, I want to move those calculations to once per frame and stored in quickly accessed video memory. As the space-independent computation gets more complex, I expect the saving to grow.</div><div><br></div></div><div class="gmail_extra">Thanks again,  </div><div class="gmail_extra">-- Conal</div><div class="gmail_extra"><br></div><div class="gmail_quote">On Tue, Jul 18, 2017 at 12:08 PM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class="gmail-"><br>
<br>
Am Dienstag, den 18.07.2017, 08:34 -0700 schrieb Conal Elliott:<br>
> I'm seeing what looks like repeated computation under a lambda with<br>
> `-O` and `-O2`. The following definition:<br>
><br>
> > exampleC :: Double -> Double -> Double<br>
> > exampleC = \ t -> let s = sin t in \ x -> x + s<br>
><br>
> yields this Core:<br>
><br>
> > -- RHS size: {terms: 13, types: 6, coercions: 0}<br>
> > exampleC :: Double -> Double -> Double<br>
> > exampleC =<br>
> >   \ (t_afI6 :: Double) (eta_B1 :: Double) -><br>
> >     case eta_B1 of _ { D# x_aj5c -><br>
> >     case t_afI6 of _ { D# x1_aj5l -><br>
> >     D# (+## x_aj5c (sinDouble# x1_aj5l))<br>
> >     }<br>
> >     }<br>
<br>
</span>ghc -O -dverbose-core2core shows you that the problem is this phase:<br>
<br>
==================== Simplifier ====================<br>
  Max iterations = 4<br>
  SimplMode {Phase = 2 [main],<br>
             inline,<br>
             rules,<br>
             eta-expand,<br>
             case-of-case}<br>
<br>
It does not happen with -fno-do-lambda-eta-expansion (but you’d lose in<br>
other parts.)<br>
<span class="gmail-"><br>
> I'm concerned because many of my uses of such functions involve<br>
> computations dependent only on `t` (time) but with millions of uses<br>
> (space) per `t`. (I'm working on a GHC Core plugin (compiling to<br>
> categories), with one use generating graphics GPU code.)<br>
<br>
</span>Did you measure whether this really is a problem? The benefits of not<br>
dealing with dynamically allocated functions might outweigh the cost of<br>
recalculating sin.<br>
<br>
Greetings,<br>
Joachim<br>
<span class="gmail-HOEnZb"><font color="#888888">--<br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.<wbr>de/</a><br>
</font></span><br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div></div>