https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #28 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #27) > On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > > > --- Comment #26 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> --- > > Yes true. > > > > By the way, your first patch did improve things a bit. If it's not too > > invasive > > could it be possible to commit it for GCC 7? > > It's not really in the shape for being committable. I'll see if I can > come up with sth better early in stage1 that might be back-portable. Thanks. > > > I think I'll try the approach you suggested in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498#c10 and see if I get some > > better results. > > For this case distance is minimal already so I don't expect you can > do anything (there's also not really separate dataflow for hoisting). If I remember well the key in the benchmark was that the basic block where the code was hoisted from could be reached by a much longer path. So although it was hoisted to a direct predecessor, sometime that value had to be kept for a very long time.
