03-Apr-2014 00:39, Walter Bright пишет:
On 4/2/2014 12:03 PM, Dmitry Olshansky wrote:
SwitchCallStatment:
goto CallExpression;
Semantics:
Same as that of a function call expression except:
a) Can Switch-Call only to a function with the same return type.
b) Anything below this statement is unreachable, i.e. treat it as return.
c) Stack frame of the current function is overwritten with that of
switched-to
function. In other words after a switch-call stack looks as if the
switched-to
function was called instead in the first place.
The last point is what modern tail-call optimizations do when one has 2
functions that tail-recurse to each other. They overwrite stackframes
on such
tail calls.
How is this different from simply recognizing "return foo(arg);" as
being a goto?
If we can alter semantics of
return foo(arg);
to _always_ be a goto, guarantee a jump and reuse of the stack, then
I'm all for it.
However this only happens with certain optimization switch which IMO
makes the
thing totally unreliable. In fact I even observed that I could implement
threaded-code interpreter by relying on tail-call optimization with
LDC, but
only when compiling with all optimizations enabled. Unoptimized builds
simply
blowup stack. This "semantics are tied to optimization" is a situation
that I
hate about C/C++ and would hope to address in D.
Doesn't seem terribly different than the "force inline" feature discussion.
Yes, it shows the same problem: semantics and optimization are often
mixed up. In this case however a program would segfault if the relevant
optimization was not performed, it's not just be many times slower.
--
Dmitry Olshansky
