https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #12 from Michael Meissner <meissner at linux dot vnet.ibm.com> --- On Fri, Feb 05, 2016 at 11:57:05PM +0000, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404 > > Bill Schmidt <wschmidt at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jakub at gcc dot gnu.org, > | |meissner at gcc dot gnu.org, > | |rguenth at gcc dot gnu.org, > | |segher at gcc dot gnu.org > > --- Comment #11 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- > After discussing with Segher offline, I think the way forward will be to > change > the definition of these fusion peepholes for now. Instead of nesting the > plus, > we can probably just add an argument to the UNSPEC to keep track of the extra > operand. If necessary, we can perhaps add a note to hold the full address; > not > sure that the final few passes would care. > > This would be just a workaround for GCC 6 since this should really be > considered a blocker. In GCC 7 the fusion patterns are supposed to be > introduced earlier and last longer, and the nested plus will cause > difficulties > all over the place, so this needs to be rethought. > > CCing the release managers for consideration of this as a P1 blocker. Another option for GCC 6 is just to disable fusion. I'm not sure we've seen any real benefits from it.
