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

[Dennis Luehring]

Am 20.09.2013 16:37, schrieb Benjamin Kramer:
> On 20.09.2013, at 15:02, Dennis Luehring <dl.soluz at gmx.net> wrote:
>
> > 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?
>
> Yes, it should catch this case.
>
> >> 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
>
> The trip count computation is just a bug and I'm working on fixing that, then the code will be a lot cleaner. Sadly, removing the allocation is harder. LLVM doesn't seem to be able to forward the values copied into the vector to the values taken out of the vector. If that's done the allocation could be deleted as dead code, LLVM already understands new/delete.
>

sounds all very good - i hope to see these bugs getting fixed, the 
"forward the values copied into the vector" problems seems to be also 
evil for other situations of optimization