Will the compiler optimize functions which return structures with fixed size arrays?

Question

Assuming I have a struct in C/C++ with fixed size array members, for example:

#define SIZE 10000
struct foo{
  int vector_i[SIZE];
  float vector_f[SIZE];
};

and I would like to create a function that will return an instance of foo, like:

foo func(int value_i, float value_f){
  int i;
  foo f;
  for(i=0;i<SIZE;i++) f.vector_i[i] = value_i;
  for(i=0;i<SIZE;i++) f.vector_f[i] = value_f;
  return f;
}

If I call the function using:

foo ff = func(1,1.1);

will the compiler perform some kind of optimization (ie TCO)?

Will the executable fill directly ff variable, or it will fill first f of func and then copy all values from f to ff?

How can I check if the optimization is performed?

Answer 1

My answer applies to c++.

Will the compiler perform some kind of optimization (ie TCO)?

By TCO do you mean "tail call optimization"? The function doesn't make a function call at the end (a tail call, if you will), so that optimization doesn't apply.

The compiler can elide the copy from the return value to the temporary due to named return value optimization. The copy-initialization from the temporary can also be elided.

---

How can I check if the optimization is performed?

By reading the generated assembly code.

If you can't read assembly, another approach would be to add copy and move constructors that have side effects and observe whether those side effects occur. However, modifying the program can have effect on whether the compiler decides to optimize (but side effects are not required to prevent copy elision).

---

If you don't want to rely on optimization, you should explicitly pass an exiting object to the function by reference (pointer in c), and modify it in place.

---

Standard reference for copy elision [class.copy] §31 (current standard draft)

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects. [...]

The section describes the criteria, which are met in this case. The quote was generated from the standard document draft at 2016-04-07. Numbering may vary across different versions of the standard document and rules have slightly changed. The quoted part has been unchanged since c++03, where the section is [class.copy] §15.

Answer 2

This is pretty well documented in Agner Fog's Calling Conventions document, § 7.1 Passing and returning objects, Table 7. Methods for returning structure, class and union objects.

A struct, class or union object can be returned from a function in registers only if it is sufficiently small and not too complex. If the object is too complex or doesn't fit into the appropriate registers then the caller must supply storage space for the object and pass a pointer to this space as a parameter to the function. The pointer can be passed in a register or on the stack. The same pointer is returned by the function. The detailed rules are given in table 7.

In other words, large return objects get constructed directly in the caller supplied buffer (on the caller's stack).

An extra copy is still required if the identity of the object to return is not known at compile time, e.g.:

foo func(bool a) {
    foo x, y;
    // fill x and y
    return a ? x : y; // copying is required here
}