On Sat, 5 Nov 2022, Philipp Tomsich wrote:
> Alexander,
>
> I had missed your comment until now.
Please make sure to read replies from Jeff and Palmer as well (their responses
went to gcc-patches with empty Cc list):
https://inbox.sourceware.org/gcc-patches/ba895f78-7f47-0f4-5bfe-e21893c4...@ispras.ru/T/#m7b7e5708b82de3b05ba8007ae6544891a03bdc42
For now let me respond to some of the more prominent points:
> > I think this leads to a counter-intuitive requirement that a hand-written
> > inline asm must sign-extend its output operands that are bound to either
> > signed or unsigned 32-bit lvalues. Will compiler users be aware of that?
>
> I am not sure if I fully understand your concern, as the mode of the
> asm-output will be derived from the variable type.
> So "asm (... : "=r" (a))" will take DI/SI/HI/QImode depending on the type
> of a.
Yes. The problem arises when 'a' later undergoes conversion to a wider type.
> The concern, as far as I understand would be the case where the
> assembly-sequence leaves an incompatible extension in the register.
Existing documentation like the psABI does not constrain compiler users in any
way, so their inline asm snippets are free to leave garbage in upper bits. Thus
there's no "incompatibility" to speak of.
To give a specific example that will be problematic if you go far enough down
the road of matching MIPS64 behavior:
long f(void)
{
int x;
asm("" : "=r"(x));
return x;
}
here GCC (unlike LLVM) omits sign extension of 'x', assuming that asm output
must have been sign-extended to 64 bits by the programmer.
Alexander
