is there a optimizing opportunity for const std::vector + std::initializer_list replaced with std::array?

[Marc Glisse]

(gcc-help@gcc.gnu.org would have been a better list)

On Fri, 20 Sep 2013, Dennis Luehring wrote:

> gcc 4.8.1, -O3 -march=native -std=c++11
>
> small example program to check what does the gcc 4.8.1 optimizer do with 
> const std::vector/std::arrays + simple operations
>
> ---
> #include <vector>
> #include <numeric>
> #include <array>
>
> #define USE_ARRAY
>
> #if defined(USE_ARRAY)
> static int calc(const std::array<int,3> p_ints, const int& p_init)
> #else
> static int calc(const std::vector<int> p_ints, const int& p_init)
> #endif
> {
>  return std::accumulate(p_ints.begin(), p_ints.end(), p_init);
> }
>
> int main()
> {
>  const int result = calc({10,20,30},100);
>  return result;
> }
> ---
>
> gcc produces this code if USE_ARRAY is defined
>
> main:
>    mov    eax, 160
>    ret
>
> if USE_ARRAY is undefined (and vector is in use) it produces
[long expected code]
> so my questions is - can gcc replace/subtitute the const std::vector by const 
> std::array in such const situations, to get better
> optimizer results or is the STL itself responsible for beeing optimizeable 
> like that - or does that brake any standard definitions?

We don't perform such high-level optimizations. But if you expand, inline 
and simplify this program, the optimizers sees something like:

p=operator new(12);
memcpy(p,M,12); // M contains {10, 20, 30}
res=100+p[0]+p[1]+p[2];
if(p!=0) operator delete(p);

A few things that go wrong:
* because p is filled with memcpy and not with regular assignments, the 
compiler doesn't realize that p[0] is known.
* the test p != 0 is unnecessary (a patch that should help is pending 
review)
* we would then be left with: p=new(12); delete p; return 160; gcc knows 
how to remove free(malloc(12)) but not the C++ variant (I don't even know 
if it is legal, or what conditions and flags are required to make it so).

Please go to the gcc bugzilla and file an enhancement request (category 
tree-optimization) if these problems are not there yet.

-- 
Marc Glisse