This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question regarding constraint usage within inline asm

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]