https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #25 from Peter Bergner <bergner at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #23) > Before RA we have asm inputs > [ > (reg/v:SI 196 [ n ]) > (reg/v:SI 4 $4 [ r4 ]) > (reg/v:SI 5 $5 [ r5 ]) > (reg/v:SI 6 $6 [ r6 ]) > (reg/v:SI 7 $7 [ r7 ]) > (reg/v:SI 8 $8 [ r8 ]) > (reg/v:SI 9 $9 [ r9 ]) > ] > (and $2 an earlyclobber). But then IRA decides > > Disposition: > 0:r195 l0 2 1:r196 l0 2 Vlad can verify, but I don't think IRA takes early clobber constraints into consideration when computing conflicts, so I'm not surprised pseudo 196 (ie, n) is assigned hard register $2. In that case, LRA will notice the illegal constraint usage and will insert reloads. > Peter, do you know which patch fixed this (is that the one you quoted > above?), > and if it could feasibly be backported separately? Yes, I think the patch I mentioned above should stop LRA from spilling the hard register assigned by the user in %0 and should instead spill pseudo 196 by reassigning it to another hard register. Whether it's feasible to backport, maybe? :-) The lra-constraints.c hunk applies to gcc-8 (with fuzz), so maybe that's enough to fix this? Can someone try applying that hunk and does it fix this?
