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

Marc Glisse marc.glisse@inria.fr
Fri Sep 20 08:46:00 GMT 2013


On Fri, 20 Sep 2013, Dennis Luehring wrote:

> 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?

-fdump-tree-optimized
(it creates a new file)

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

http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html
(the PR number is in the ChangeLog entry)

-- 
Marc Glisse



More information about the Gcc mailing list