On Tuesday, 14 January 2014 at 19:05:22 UTC, Peter Alexander
wrote:
On Tuesday, 14 January 2014 at 18:38:27 UTC, David Nadlinger
wrote:
On Tuesday, 14 January 2014 at 16:31:00 UTC, Dicebot wrote:
So it does inline but end result is still less optimal
assembly-wise.
The problem, by the way, seems to be that the program actually
contains two loops that LLVM cannot merge: One in the filter()
constructor (skipping the initial run of even elements), and
the actual foreach loop in main().
David
I wonder if there is some way the language could help with that
in the common case. For example, provide an opApply for all
non-infinite ranges that can be used with foreach instead of
front/empty/popFront. I imagine opApply is much easier to
inline and optimise than trying to piece range operations and
state back together to see the underlying loop.
Actually, you could give an opApply for infinite ranges too.
foreach loops can have breaks, and opApply knows how to handle
them.
