would there ever be sharing parts of caller/callee stack frames?

Question

I was wondering Are these scenarios ever possible for a compiler to do?

first we define SomeDataType as:

struct SomeDataType{
public:
int a;
int b;
int c;
};

Scenario #1_regarding a callee function having reference parameter like this:

void doSomething(SomeDataType & input){
...
}

assuming the function isn't inline and only variables in scopes of caller functions are passed to this function in a program and regarding the fact that references aren't necessarily pointers, the part of memory where the input argument is placed is shared between stack frame of any caller function and stack frame of "doSomething" callee function so that "doSomething" can address that parameter just the way it addresses any local variable in its local scope which is by adding offset to a base pointer that determines beginning address of its stack frame.

Scenario #2_This seems more improbable to me but anyway; regarding a callee function that returns a structure of type "SomeDataType":

SomeDataType doSomething(){
SomeDataType someStruct;
...
return someStruct;
};

the part of memory where the structure "someStruct" resides is shared between stack frame of any caller and stack frame of "doSomething" callee function so considering the following statement in a caller function:

SomeDataType TheStruct=doSomething();

in the scope of that caller using "TheStruct" results in using the same part of memory where "SomeStruct" in the scope of callee resides meaning basically the callee function doesn't copy "someStruct" anywhere and even if copying was necessary like when there was a statement like below in a caller function indicating that destination isn't a structure in the caller scope:

*pntrToSomewhere=doSomething();

it'll be the caller duty to copy contents of that shared part to where that pointer tells.

Are you maybe talking about RVO? – PlasmaHH Jun 27 '13 at 09:13 — PlasmaHH, Jun 27 '13 at 09:13

score 0 · Answer 1 · answered Jun 27 '13 at 09:12

If you pass a reference (or pointer) to a local variable in the calling function (caller), then that will be on the caller stackframe. Note that I'm not aware of any architecture, where if you lift the carpet and look at how it's actually working under the pretty surface, references aren't actually pointers. The standard doesn't REQUIRE that, but it is how it is implemented for at least most architectures - I'd actually be interested in understanding HOW ELSE you could implement it - but I haven't spent much time thinking about it.

The typical behaviour of a function that has a struct or class return type is that it passes an "extra" argument pointing to a temporary space to store the return type, e.g.:

 T myfunc(int x, int y)

 ...

 void foo()
 {
    ...
    T x = myfunc(2, 18);
    ...
 }

will appear the same as (the hidden argument won't necessarily be the FIRST argument - but it's almost certainly either first or last):

 void myfunc(T& hidden, int x, int y)

 void foo()
 {
    ...
    T x;
    myfunc(x, 2, 18);
    ...
 }

It is not really that the stackframe is shared, as much as "we pass pointers that are in the stackframe of the or another, earlier, caller.

So, yes, there can be accesses from the current callee into an earlier callers stackframe, for sure.

as far as I know reference isn't pointer when the function is inlined it is just an alias in that case for what it refers to and in scenario#1 I intentionally stated function is not inlined to exclude this case, and as with that mechanism you described that's called RVO(return value optimization) but not what I meant — Pooria, Jun 27 '13 at 10:05

would there ever be sharing parts of caller/callee stack frames?

1 Answers1