On 26.08.2016 10:44, kink wrote:
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?

Better performance is better even when it is not the primary concern.

A compiler penalizing such bad coding style is absolutely fine by me.

It's not the compiler's business to judge coding style, also:

// 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));
}

Reply via email to