Optimisation possibilities: current, future and enhancements

[kink via Digitalmars-d]

On Friday, 26 August 2016 at 05:50:52 UTC, Basile B. wrote:
> On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote:
>> On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote:
>> From my perspective, the problem with this example isn't 
>> missed optimization potential. It's the code itself. Why waste 
>> implementation efforts for such optimizations, if that would 
>> only reward people writing such ugly code with an equal 
>> performance to a more sane `2 * foo.foo()`? The latter is a) 
>> shorter, b) also faster with optimizations turned off and c) 
>> IMO simply clearer.
>
> You're too focused on the example itself (Let's find an non 
> trivial example, but then the asm generated would be longer). 
> The point you miss is that it just *illustrates* what should 
> happend when many calls to a pure const function are occur in a 
> single sub program.

I know that it's just an illustration. But I surely don't like 
any function with repeated calls to this pure function. Why not 
have the developer code in a sensible style (cache that result 
once for that whole 'subprogram' manually) if performance is a 
concern? A compiler penalizing such bad coding style is 
absolutely fine by me.