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

Dennis Luehring dl.soluz@gmx.net
Fri Sep 20 08:39:00 GMT 2013


Am 20.09.2013 07:50, schrieb 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.
>

can you give more details about what you've done in "...But if you 
expand, inline and simplify this program, the optimizers sees something 
like..."
have you done it manualy or?

he test p != 0 is unnecessary (a patch that should help is pending 
review) <- do you know the bugzilla entry?



More information about the Gcc mailing list