Optimisation possibilities: current, future and enhancements

[Basile B. via Digitalmars-d]

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:
> I'm wondering if there are more opportunities in D for 
> increased optimization in compilers that have not been mined 
> yet. I'm specifically interested in the possibilities of D over 
> and above what is possible in C and C++ because of the 
> characteristics of D or because of our freedom to change 
> compared with the inertia in the C/C++ world.
>
> [...]
> Sorry it's such a paltry list. However discussion will I'm sure 
> expand it.

I'll add

* create temporaries based on the const function attribute.

I don't know why but I believed that it was already the case. 
After disassembling a short test with DMD and LDMD2 it appears 
clearly that this is not true:

°°°°°°°°°°°°°°°°°°°°°°°°°°
struct Foo
{
     immutable _u = 8;
     int foo() const
     {
         return 8 * _u;
     }
}
int use(ref const(Foo) foo)
{
     return foo.foo() + foo.foo();
}
°°°°°°°°°°°°°°°°°°°°°°°°°°

disasm of use (LDC2 via LDMD2, -O -release)

0000000000402930h  sub rsp, 18h
0000000000402934h  mov qword ptr [rsp+10h], rdi
0000000000402939h  call 00000000004028F0h ; (Foo.foo)
000000000040293Eh  mov rdi, qword ptr [rsp+10h]
0000000000402943h  mov dword ptr [rsp+0Ch], eax
0000000000402947h  call 00000000004028F0h ; (Foo.foo)
000000000040294Ch  mov ecx, dword ptr [rsp+0Ch]
0000000000402950h  add ecx, eax
0000000000402952h  mov eax, ecx
0000000000402954h  add rsp, 18h
0000000000402958h  ret

But Foo.foo constness guarantees that Foo state is not modified. 
So the result of the first CALL could be cached in a temporary 
and reused instead of the second CALL. This would help for 
example in loops when a getter function is called to know the 
iteration count.