New linked list

[Sean Kelly]

Dave wrote:
> 
> Maybe I'm taking this out of context because I just jumped into this 
> thread, but...
> 
> I think a D compiler (because foreach is built-in) could safely optimize 
> those three w/o a lot of magic right now.
> 
> For #1, neither sum nor val are references and there isn't a call 
> outside of the loop scope. So I think a compiler could determine that 
> and fully optimize w/ parallelization or whatever.
> 
> The 2nd one calls outside of the loop scope, so the compiler could keep 
> track of that to determine that it can't safely do any optimization 
> where the elements may be unordered. Even if it is a call to something 
> like putc which is then inlined, it must eventually make a call and/or 
> write a value to a hardware reference, either of which - call or 
> dereference - the optimizer could flag as "can't use an unordered 
> optimization".
> 
> IIRC, the 3rd one is undefined behavior because the aggregate is 
> modified inside the loop. But even if it wasn't, the same restrictions 
> for #2 could be put on it because it calls outside of the loop scope.

I think you're right.  I'll admit much of my confusion here is a result 
of not knowing just how aggressive current optimization strategies are. 
  Also, this seems like a good opportunity to explore how this might 
extend to implicit parallelization and such, which seems to follow 
similar rules but isn't at all common (I think the Intel compiler does 
parallel loop unrolling in certain instances, but that's about it). 
Ideally, it would be nice if there were some means of allowing 
optimizations to take place for which there currently isn't enough 
information, similar to the various levels of parallelization in the C++ 
example.  But at the very least I'd be happy if I didn't have to give up 
on foreach altogether in instances where the result should be 
well-defined before optimizations take place (#3 is a still undefined, 
but my linked list example should not be).


Sean