https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #37 from Peter Bergner <bergner at gcc dot gnu.org> --- (In reply to Rich Felker from comment #30) > The code has been working for the past 8 years with the "0"(r2) input > constraint added, and would clearly be valid if r2 were pre-initialized with > something. I think using "0"(r2) is a valid workaround for older compilers and I can't think of a reason why there should be a problem with it. Currently, IRA doesn't look at early clobbers when computing conflicts, so "r2" and "n" do not conflict, since "n" is an input operand of the asm and never used again and "r2" is an output operand of the asm (ie, their lifetimes don't overlap...ignoring the early clobber). Since they don't conflict (in IRA), it's possible they can be assigned the same hard register depending on the phase of the moon, etc., which they are here. LRA which does look at early clobbers sees the problem and emits reloads to correct it, but with the old unfixed bug, it spills the wrong thing. Adding that extra input operand will make the pseudo for "r2" conflict with the pseudo for "n", even in IRA. That will force them to get different hard registers and since "r2" is preassigned by you to $2, "n" will be assigned to something else. Problem solved. Now the extra input operand usage will cause the lifetime of "r2" to reach back to the start of the function this is inlined in, so it won't be able to share the same hard register with any other pseudo that is used then (maybe just the basic block it's in?). You could mitigate that by inserting a simple "r2 = 0;" just before the inline asm, which will truncate its live range. Yes, it's an extra insn, but it is a simple/inexpensive one.
