powerpc Linux scv support and scv system call ABI proposal

[Segher Boessenkool]

Hi again,

On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
> > This is why that *is* the only supported use.  The documentation could
> > use a touch-up, I think.  Unless we still have problems here?
> 
> I really don't know.  GCC still has *some* support for the old behavior,
> though.

No.  No support.  It still does some of the same things, but that can
change (and probably should).  But this hasn't been supported since the
dark ages, and the documentation has become gradually more explicit
about it.

> For example, local register variables are treated as
> initialized, and I think you can still use registers like global
> variables.  GCC does not perform copy propagation here:
> 
> int f1 (int);
> 
> int
> f (void)
> {
>   register int edi __asm__ ("edi");
>   int edi_copy = edi;
>   return f1 (1) + edi_copy;
> }

f:
        pushl   %edi
        subl    $20, %esp
        pushl   $1
        call    f1
        addl    %edi, %eax
        addl    $24, %esp
        popl    %edi
        ret

It takes the edi value *after* the call.  The behaviour is undefined,
so that is not a problem.  (This is a GCC 10 from September, fwiw).

> And the case that we agreed should be defined in fact is not:
> 
> void f1 (int);
> 
> int
> f (void)
> {
>   register int edi __asm__ ("edi");
>   asm ("#" : "=r" (edi));
>   f1 (1);
>   return edi;
> }

f:
        pushl   %edi
        subl    $20, %esp
#APP
        #
#NO_APP
        pushl   $1
        call    f1
        movl    %edi, %eax
        addl    $24, %esp
        popl    %edi
        ret

Changing it to "# %0" (so that we can see what we are doing) gives

#APP
        # %edi
#NO_APP

All as expected.

> On x86-64,

Oh, this was i386, since you used edi.  On x86-64:

f:
        pushq   %rbx
        movl    %edi, %ebx
        movl    $1, %edi
        call    f1
        addl    %ebx, %eax
        popq    %rbx
        ret

for that first testcase, taking edi before the call, which is not
*guaranteed* to happen, but still can; and

f:
        subq    $8, %rsp
        movl    $1, %edi
        call    f1
        addq    $8, %rsp
        movl    %edi, %eax
        ret

The asm was right before that "mov $1,%edi", so it was optimised away:
it is not a volatile asm, and its output is unused.  Making the asm
statement volatile gives

f:
        subq    $8, %rsp
#APP
        # %edi
#NO_APP
        movl    $1, %edi
        call    f1
        addq    $8, %rsp
        movl    %edi, %eax
        ret

> %edi is used to pass the first function parameter, so the
> call clobbers %edi.  It is simply ambiguous whether edi (the variable)
> should retain the value prior to the call to f1 (which I think is what
> should happen under the new model, where register variables are only
> affect asm operands), or if edi (the variable) should have the value of
> %edi (the register) after the call (the old model).

There is nothing ambiguous there, afaics?  Other than the edi value you
use in the asm is coming out of thin air (but it will always work with
current GCC; that's not really specified though).

> Should we move this to the gcc list?

Whoops, I thought that was on Cc:.  Sure.


Segher