Optimisation possibilities: current, future and enhancements

[kink via Digitalmars-d]

On Friday, 26 August 2016 at 09:30:52 UTC, Timon Gehr wrote:
> Better performance is better even when it is not the primary 
> concern.
> It's not the compiler's business to judge coding style

It's free to choose not to implement complex optimizations just 
so that people get super duper performance for crappy code, 
especially with the limited manpower we got. Fixing severe DMD 
bugs (there are still enough of those) is 100x more important.

> // original code. not "bad".
>
> int foo(int x) pure{ ... }
>
> int bar(int x) pure{ return foo(x) + foo(5-x); }
>
> void main(){
>     writeln(bar(5));
> }
>
> // ==> inlining
>
> void main(){
>     writeln(foo(5)+foo(10-5));
> }
>
> // ==> constant folding, "bad" code
>
> void main(){
>     writeln(foo(5)+foo(5));
> }

Inlining and subsequent constant folding are only available if 
the callee isn't an external. For those cases, existing LLVM/GCC 
optimizations kick in and render at least this idea (automatic 
caching of pure function calls) obsolete (in most cases), see the 
LDC asm.
This is my main point. Higher-level, D-specific optimizations 
would be nice, but modern backends, coupled with optimized builds 
(`ldc2 -singleobj m1.d m2.d ...`) eat some of the ideas here for 
breakfast. So I'd focus on cases where LDC/GDC don't exploit 
optimization potential already.