This is the mail archive of the gcc-patches@gcc.gnu.org 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: [RFA:] Improve "asm-reg in asm" documentation (was: Re: [m68k]asm regression with 3.3/3.4/3.5)


(Let's continue this thread on gcc-patches only.  If you agree,
please prune the CC list in any reply.)

On Mon, 13 Sep 2004, Gunther Nikl wrote:
>   After I was told, that my expectations were wrong

Heh, GCC maintainer opinions count just a little bit more,
because they get into the code. ;-)  IIRC no maintainer has
expressed that view.

> and I re-read the
>   documentation. Indeed it wasn't clear on this issue and my usage of
>   local register variables and extended asm could be viewed as wrong
>   according the docs.

Not without at least contradiction, IMHO.  If it is, we'd have
to invent new machinery for this situation anyway.

(Hmm, a "portable" generic multi-character-constraint prefix,
one that prefixes a register number or a target-specific
register name?)

> > + @smallexample
> > + register int *p1 asm ("r0") = @dots{};
> > + register int *p2 asm ("r1") = @dots{};
> > + register int *result asm ("r0");
> > + asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
> > + @end smallexample
> > +
>
>   This is exactly what m68k-amigaos does.

And cris-axis-linux-gnu (surprise) and IIRC others too, at least
m68k-*-linux-gnu.

> There is still something that
>   might need an explanation: the choosen register for p1 might be scratch
>   register and assigned value to p2 might come from a function call. Could
>   that cause probelms?

Oh dear.  Presumably yes.  (Wasn't this discussed?  I forget.)
I'm of two minds on this:

1. If that's what happens, it's a bug; a local asm variable
that's declared as a call-clobbered register shouldn't be
clobbered by calls, but instead saved around calls.  After all,
for expressions (like the second @dots{} above) that may contain
a call you'd then always need the awful two-stage approach you
describe, and it must be certain that no assignment to an
asm-reg-variable can make a library call.  (I think that's
pretty safe, though, assuming only scalars are used.)

2. You asked for it and you're supposed to know what to do when
picking registers for asm variables, so if there's a call (even
a libcall; one not visible in the user code) between the
variable assignment and the asm use, then the variable is
clobbered and you're to blame for writing bad code.

If we go for (2), I think it's not that hard to diagnose and
emit a warning when the clobber may happen, and that a
default-on warning is in order.

> Currently it doesn't but then m68k-amigaos uses a
>   two-stage approach: first all arguments to the register vars are assigned
>   to local vars which then are used as inputs to the register vars. I suppose
>   this was done to help GCC.

(Hey, just read the clarifying comment above the "extra" stage
in that syscall code!  Wot, comment missing there? ;-)

Well, it's either to work around a bug or because you need to do
that.  Until it's documented, I'd say it's a bug.  Is there a PR
for this?

>   Thank you for writing this clarification. Hopefully, it describes what
>   really is supposed to happen.

FWIW, I'm quite sure and the opinion has been shared by
approvers of my bug-fixes for this functionality in the past.

brgds, H-P


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