public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat•com>
To: Segher Boessenkool <segher@kernel•crashing.org>
Cc: libc-alpha@sourceware•org,
	Tulio Magno Quites Machado Filho <tuliom@linux•ibm.com>,
	linuxppc-dev@lists•ozlabs.org,
	Nicholas Piggin <npiggin@gmail•com>
Subject: Re: powerpc Linux scv support and scv system call ABI proposal
Date: Thu, 30 Jan 2020 13:03:53 +0100	[thread overview]
Message-ID: <87y2tp40d2.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200130112512.GS22482@gate.crashing.org> (Segher Boessenkool's message of "Thu, 30 Jan 2020 05:25:12 -0600")

* Segher Boessenkool:

>> I *assumed* that I would still get
>> the value of r0 (the register) from the associated extended asm in this
>> expression, even if it may now be a different register.  Your comment
>> made me think that this is undefined.
>
> Please show full(er) examples, I think we are talking about something
> else?

No, I think we are in agreement here how things should behave under the
new model.  But I have doubts whether that is implemented in GCC 9.

>> The GCC documentation has this warning:
>> 
>> |  _Warning:_ In the above example, be aware that a register (for
>> | example 'r0') can be call-clobbered by subsequent code, including
>> | function calls and library calls for arithmetic operators on other
>> | variables (for example the initialization of 'p2').
>
> Yes.  This does not matter for the only supported use.

I'm not so sure.  See below.

> 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.  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;
}

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;
}

On x86-64, %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).

Should we move this to the gcc list?

Thanks,
Florian


  reply	other threads:[~2020-01-30 12:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-28 10:50 powerpc Linux scv support and scv system call ABI proposal Nicholas Piggin
2020-01-28 13:09 ` Florian Weimer
2020-01-28 14:05   ` Nicholas Piggin
2020-01-28 15:40     ` Segher Boessenkool
2020-01-28 16:04       ` Florian Weimer
2020-01-28 20:01         ` Segher Boessenkool
2020-01-29 16:19           ` Florian Weimer
2020-01-29 16:29             ` Segher Boessenkool
2020-01-29 17:02               ` Florian Weimer
2020-01-29 17:51                 ` Segher Boessenkool
2020-01-30 10:42                   ` Florian Weimer
2020-01-30 11:25                     ` Segher Boessenkool
2020-01-30 12:03                       ` Florian Weimer [this message]
2020-01-30 13:50                         ` Segher Boessenkool
2020-01-30 17:04                           ` Adhemerval Zanella
2020-01-30 21:41                             ` Segher Boessenkool
2020-01-31 11:30                               ` Adhemerval Zanella
2020-01-31 11:55                                 ` Segher Boessenkool
2020-01-28 15:58     ` Florian Weimer
2020-01-29  4:41       ` Nicholas Piggin
2020-01-28 17:26     ` Adhemerval Zanella
2020-01-29  4:58       ` Nicholas Piggin
2020-01-29 13:20         ` Segher Boessenkool
2020-01-29 15:51         ` Tulio Magno Quites Machado Filho
2020-02-19 11:03           ` Nicholas Piggin
2020-01-28 22:14   ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2tp40d2.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat$(echo .)com \
    --cc=libc-alpha@sourceware$(echo .)org \
    --cc=linuxppc-dev@lists$(echo .)ozlabs.org \
    --cc=npiggin@gmail$(echo .)com \
    --cc=segher@kernel$(echo .)crashing.org \
    --cc=tuliom@linux$(echo .)ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox