On Fri, 20 Sep 2013, Dennis Luehring wrote:
Am 20.09.2013 07:50, schrieb Marc Glisse:
(gcc-h...@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
