foreach thoughts
Peter Alexander
peter.alexander.au at gmail.com
Tue Jan 14 11:05:20 PST 2014
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.
More information about the Digitalmars-d
mailing list