<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 January 2014 12:22, David Nadlinger <span dir="ltr"><<a href="mailto:code@klickverbot.at" target="_blank">code@klickverbot.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, 15 January 2014 at 01:42:07 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right, thanks for that.<br>
I'm quite surprised by how bad that turned out actually, and with LDC,<br>
which is usually the best at optimising that sort of thing.<br>
Need to do some intensive experimentation... but this is a bit concerning.<br>
</blockquote>
<br></div>
GCC might do some loop merging, I haven't checked. It's just that this pattern doesn't tend to appear too much in traditional C/C++ code (after all, who splits up their loops into two parts just for fun?), so it could be that the LLVM people just never really bothered to write a pass to merge single loops that have been split (as opposed to classical loop fusion, where the loop ranges are the same, but the operations performed/target data different).<br>

<br>
Maybe it would be possible to implement something like this fairly easily using the existing LLVM loop analyses though.</blockquote><div><br></div><div>Okay. As long as the problem is understood and a solution seems realistic.</div>
<div>The closure allocation is also an important problem to fix, but that one's been on the list a long time.</div></div></div></div>