On 2/20/19 9:39 PM, Alan Modra wrote: > On Wed, Feb 20, 2019 at 08:57:52PM -0600, Peter Bergner wrote: >> Yes, because they don't have my IRA and LRA patches that exposed this >> problem. I would say they were buggy for not complaining and silently >> spilling a hard register in the case where we used asm reg("..."). > > I don't follow your reasoning. It seems to me that giving some > variable a register asm doesn't mean that the value of that variable > can't appear in some other register. An obvious example is when > passing that variable to a function.
I don't disagree with you here. For sure, multiple registers can hold the same value, the same that multiple variables can hold the same value. > So why shouldn't a hard reg be reloaded in order to satisfy > incompatible constraints? About the only usage of register asm that is guaranteed, is their usage in inline asm. If you specify a hard register for a variable and then use that variable in an inline asm, you are guaranteed that that variable will use that register in the inline asm. Now in this case, "input" doesn't have the register asm, but asmcons rewrites the rtl such that it looks like "input" was assigned via a register asm. LRA doesn't know about register asms, it just sees pseudos and hard registers, so I think it needs to be conservative and assume the explicit hard registers it sees could have come from a register asm, and not spill it, but rather error out and let the user fix it. That said, the "bug" in the case we're seeing, is that asmcons rewrote all of "input"'s pseudos, and it should be more careful to not create rtl with illegal constraint usage that LRA cannot fix up. With the fix, operand %1 in the inline asm is no longer hard coded to r3 and it uses the pseudo instead, so everything is copacetic. Peter