Leopold Toetsch wrote:
> Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke:
>> Visual C++ seems to optimize quite heavily, and it looks like it reuses
>> the memory on the stack where arguments are passed for local variables.
>
>> mov dword ptr [ebp+0Ch],edx
>
> All I know about intel calling convs would summarize this as a nasty compiler
> bug, not an optimization. This statement is clearly overwrting a stack frame
> location, which doesn't belong to the called subroutine.
I took this for granted too until today. Now that I think about it I'm
wondering... The caller copies the values in and is responsible for
free(3)ing, but does it also own the data?
What about code that assumes it owns the local variable that represents
the argument.
void f(int x)
{
/* x is mine, and mine alone */
x = ...;
}
> This optimization reaches likely back to times, when the opcode engine was
> designed. It's saving one interpreter push statement [1] per JIT calling one
> external function, and I've always thought of it as a very cool (and valid)
> thingy, when I first realized, why the interpreter is the second argument in
> opcode functions ;)
I think it's a really cool idea, too. I'd like to have a way to disable
it, though, to measure its effect, and maybe to "work around" compilers
like VC (at least until a better solution comes around).
For the given example, VC uses the memory available for the local
variable C<ccont>, and the remaining data fits into the reserved stack
and the registers too, avoiding to allocate memory on the stack for the
local variables. This would probably involve a C<sub esp> and <add
esp>, which is likely more lightweight than pushing the C<interp> on the
stack, making the latter probably the better optimization in this case
still.
> [1] well at least for ancient architectures like x86, which don't have
> register calling convs for parts of the arguments
For Windows there's __fastcall, which would use ECX and EDX for the
first two int or smaller values, but I think it's rarely used
> Great analysis of the problem BTW,
> thanks,
> leo
Many thanks,
Ron
