This is the mail archive of the
mailing list for the GCC project.
Re: [m68k] asm regression with 3.3/3.4/3.5
Gunther Nikl <email@example.com> writes:
> > gcc outsmarted you. To put it another way, gcc acted reasonably
> > within the constraints as you described me.
> This is only true if GCC can ignore "register asm()", can it? If thats
> the case than this is surprsing. Why does it work with the bar call
> removed? That shouldn't change anything.
It's just a coincidence that it works when you don't call bar().
Specifying register asm() only means that any reference to that
variable will use the specified register. It doesn't mean that gcc
can't eliminate use of that variable. Read the documentation about
local register variables. In particular, note this:
This option does not guarantee that GCC will generate code that
has this variable in the register you specify at all times. You
may not code an explicit reference to this register in an `asm'
statement and assume it will always refer to this variable.
> > However, since you assumed that the input would be in A6, that didn't
> > work.
> I need all values in exactly the registers as specified. "register asm()"
> was helpful to let the compiler choose an appropriate addressing mode.
Unfortunately, gcc does not provide a mechanism to do what you are
trying to do (at least, not as far as I know). What you want is
reasonable. And your attempt at it is plausible, but the compiler
does not work that way, and is even documented as not working that
> > If you must use A6 for other reasons--if the subroutine expects
> > it--then you need to declare _bn to be volatile.
> Doesn't help.
Yes, I see now that volatile register variables do not behave as
expected. I'm not sure what that is all about.
> > Similar issues did not arise for the other register input variables,
> > because they are clobbered by the asm statement.
> I changed __v1 and __v2 to d2 and a2. GCC uses these registers (which are
> not clobbered) but for _bn it uses d3 now.
Hmmm. I guess I was wrong. Perhaps the reason that gcc is handling
A6 differently has to do with being passed in as a parameter rather
than using an immediate constant. A parameter is already in a
pseudo-register, and gcc chooses to use that pseudo-register instead
of the pseudo-register which represents _bn (and is in A6). The same
issue does not arise for an immediate constant. But I am just