http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-04 18:20:09 UTC --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 29350 [details] > > gcc48-pr56151.patch > > > > Untested patch for the peephole mentioned in previous comment. > > I don't think a new set of peepholes is an appropriate solution for > this problem, because the same issue can show up on any CISC-like > target. Before my patch, the code was good after 'expand' by optabs, > perhaps the code your peephole tries to create, can be emitted from > there instead. And perhaps, longer term, combine should be changed > to try the more profitable combination before the one it performs now. My patch wasn't meant as a replacement of the optabs.c change, but as a complement. As the sequence into which it attempts to peephole is shorter and supposedly faster on some CPUs at least, if such an insn sequence appears in the IL anywhere during RTL optimizations, it can optimize it.
