0

On the stack the compiler is free to do a lot of optimizations, because the context is static and known at compile time, but when dealing with access to dynamically allocated objects and generally accessing "by reference" the context is not known, so logically in such cases, member access boils down to dereferencing a memory address derived by adding the object base address and the offset for that member. Or does it? I am pretty new to this, so at this point I am only guessing and probably missing a lot of details.

For example I noticed that if I implement the + operator as void add(int * a, int * b, int * r); when working with stack members (and using the & operator) the assembly code is identical to that the regular + operator creates, so it does seem that pointers which are known to point to compile time known values are are being optimized to exclude extra dereferencing (and copying) and the indirections inside the add() function are inlined as direct access to stack objects. Does this mean the compiler is "good enough" to be able to optimize say accessors implemented with indirection from constant value offsets from the object base address on the stack as if using struct member access to get that value?

  • _'boils down to dereferencing a memory address derived by adding the object base address and the offset for that member'_ Hmmmm, yes! And your question is? – πάντα ῥεῖ Mar 11 '14 at 18:59
  • ^ So nothing more to it? –  Mar 11 '14 at 19:01
  • Sounds like its at least compiler implementation specific, doesn't it? You can (mostly) only rely on what's defined in the accepted C++ standards. For most of the modern compiler you can assume they're _good enough_ IMHO. – πάντα ῥεῖ Mar 11 '14 at 19:03

1 Answers1

0

I don't know how you implemented the body of the function so this answer might be completely off :).

If you are adding inside your function r = a + b , the code will look the same but won't be the same.

for the prototype (int *, int * , int *) you will add pointers which is wrong. To get the integer value inside your function, the body should be : 

*r = *a + *b ;

OR 

r[0] = a[0] + b[0];

in order to get the value which you desire. This body shouldn't have the same assembly code as the + operator since the values pointed aren't the known at compile time.

for the prototype (int &, int & , int &) and the body

r = a + b;

the compiler will inline this function, so yes, the assembly should be indentical.

MichaelCMS
  • 4,703
  • 2
  • 23
  • 29
  • I thought it goes without saying, the `add()` function is implemented using pointer indirection, e.g. `*r = *a + *b;`. The compiler generates identical assembly as the `+` operator only if the function is inlined in a static context pointing to known stack objects. The code is identical instruction for instruction. Even though the function uses pointers internally the compiler is able to tell that in the compiled context they point to stack objects, so the compiler is accessing those using the stack rather than wasting time copying pointers and indirecting from there. –  Mar 12 '14 at 08:15
  • Well, compiler theory isn't my top skill, but if you are using pointer indirection, maybe the compiler figures out that you are passing a pointer which you then de-reference, so to avoid this, it just inlines the function and instead of using aditional registries to keep the pointer values (*a,*b*,*c) then dereference them, it skips this step, resulting in identical code as the + ... Try making the same test using a more complex context, where the pointers passed are not obtained using references from a previous context, but are heap-allocated integers (something like *a = new int[1]). – MichaelCMS Mar 21 '14 at 08:44