[cfe-dev] missing optimization opportunity for const std::vector compared to std::array

Dennis Luehring dl.soluz at gmx.net
Fri Sep 20 06:02:03 PDT 2013


Am 20.09.2013 14:49, schrieb Benjamin Kramer:
> On 20.09.2013, at 13:33, Dennis Luehring <dl.soluz at gmx.net> wrote:
>
> > i've written this small testprogram to test the gcc4.8.1 optimizer and found a optimization opportunity
> >
> > for details see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
> >
> > then i compared the gcc results to clang 3.3 and found that the optimization of llvm "seems" to be far aways from the gcc results in this case
>
> What you're seeing in the std::array case is likely an artifact of running the loop vectorizer too early in LLVM 3.3. This is fixed in trunk.

so the result is also

return 160;

for the trunk version?


> The std::vector case is trickier, I think the main problem here is that the optimizer wasn't able to see that the loop inside std::accumulate has a constant trip count.

so the problem in the llvm optimizer is different to the gcc one?

the gcc understands the constant trip count, but threre is no rule for 
removing unneeded allocation with new/delete
the gcc can only remove malloc/free - but its ongoing work






More information about the cfe-dev mailing list