clobbering input args in inline asm

clobbering input args in inline asm

[Stas Sergeev]

Hi.

As probably many of the new gcc users, I stumbled over
the fact that gcc allows an inline asm to modify the
input arguments, and there seem to be no other way
of preventing that, than to use the dummy output var.
And, just as all the others who stumbled over this, I
found that solution counter-intuitive. So I tried some
other things, and now I have a few questions.
Below is the program that prints the different results
when compiled with -O0 and -O2, and the fact that the
asm constraints are broken, is really counter-intuitive,
IMHO.

My questions are:
- I can't add the register both in the input list and the
clobber list, and that's perfectly documented. However, it
seems like I can add "0" in the clobber list, and gcc accepts
that. Though, it still doesn't give the right code. I wasn't
able to find in the gcc manual, nor in the google, what will
the "0" mean in the clobber list - so what is it?
- Another strange thing is that I can add "0" in the clobber
list if it refers to any of the register classes (on i386
target), but not to "a". I.e. if I have "b" in input and "0"
in clobber - gcc eats that. If I have "a" in input and "0"
in clobber - gcc complains. What is the reason?
- Why wouldn't gcc just allow the "&" modifier in the
input list? Just like in the output list it means early-clobber,
in the input list it could mean late-clobber, i.e. clobbered
after the value was taken.

Sorry for the novice questions. This is mainly just my curiosity
and the fact that I find an official solution very confusing and
counter-intuitive.

Thanks for any info.


The test-case:
---
#include <stdio.h>

volatile int a = 5;

int main()
{
  int b = a;
  asm volatile ("movl $0, %%ebx\n" :: "b"(b));
  printf("%i\n", b);
  return 0;
}
---
Prints 5 when compiled with -O0, and 0 when compiled with -O1.

Re: clobbering input args in inline asm

[Andrew Haley]

Stas Sergeev writes:
 > Hi.
 > 
 > As probably many of the new gcc users, I stumbled over
 > the fact that gcc allows an inline asm to modify the
 > input arguments, and there seem to be no other way
 > of preventing that, than to use the dummy output var.
 > And, just as all the others who stumbled over this, I
 > found that solution counter-intuitive. So I tried some
 > other things, and now I have a few questions.
 > Below is the program that prints the different results
 > when compiled with -O0 and -O2, and the fact that the
 > asm constraints are broken, is really counter-intuitive,
 > IMHO.
 > 
 > My questions are: - I can't add the register both in the input list
 > and the clobber list, and that's perfectly documented. However, it
 > seems like I can add "0" in the clobber list, and gcc accepts that.

The clobber list is for physical register names such as "ebx", not for
operands.  This is for asms that must clobber specific physcial
registers.

----------------------------------------------------------------------
 Some instructions clobber specific hard registers.  To describe this,
write a third colon after the input operands, followed by the names of
the clobbered hard registers (given as strings).  Here is a realistic
example for the VAX:

     asm volatile ("movc3 %0,%1,%2"
                   : /* no outputs */
                   : "g" (from), "g" (to), "g" (count)
                   : "r0", "r1", "r2", "r3", "r4", "r5");
----------------------------------------------------------------------

 >  Though, it still doesn't give the right code. I wasn't able to
 > find in the gcc manual, nor in the google, what will the "0" mean
 > in the clobber list - so what is it?

 > - Another strange thing is that I can add "0" in the clobber list
 > if it refers to any of the register classes (on i386 target), but
 > not to "a". I.e. if I have "b" in input and "0" in clobber - gcc
 > eats that. If I have "a" in input and "0" in clobber - gcc
 > complains. What is the reason?

 > - Why wouldn't gcc just allow the "&" modifier in the input list?
 > Just like in the output list it means early-clobber, in the input
 > list it could mean late-clobber, i.e. clobbered after the value was
 > taken.

 > #include <stdio.h>
 > 
 > volatile int a = 5;
 > 
 > int main()
 > {
 >   int b = a;
 >   asm volatile ("movl $0, %%ebx\n" :: "b"(b));
 >   printf("%i\n", b);
 >   return 0;
 > }

This is wrong: you're clobbering one of the inputs without telling
gcc.  Assuming you actually want the output, it should be:


#include <stdio.h>

volatile int a = 5;

int main()
{
  int b = a;
  asm volatile ("movl $0, %%ebx\n" : "=b"(b));
  printf("%i\n", b);
  return 0;
}


And if you don't want the ouput, add ebx to the clobber list:


volatile int a = 5;

int main()
{
  int b = a;
  asm volatile ("movl $0, %%ebx\n" :::"ebx");
  printf("%i\n", b);
  return 0;
}


Andrew.

Re: clobbering input args in inline asm

[Stas Sergeev]

Hi.

Andrew Haley wrote:
> The clobber list is for physical register names such as "ebx", not for
> operands.
Yes, that's why my question was not "why it still
doesn't work", but rather "what does the "0" mean, when
put in the clobber list?" gcc accepts it there, and I
wasn't able to find anywhere in the docs, what does it
mean.

> This is wrong: you're clobbering one of the inputs without telling
> gcc.
Yes, but the problem is, the way to tell this to gcc
looks very strange to me. Here's only what I've been
able to find in the docs:
---
There is no way for you to specify that an input
operand is modified without also specifying it as an output
operand.  Note that if all the output operands you specify are for this
purpose (and hence unused), you will then also need to specify
|volatile| for the |asm| construct, as described below, to
prevent GCC from deleting the |asm| statement as unused.
---
A quick googling shows many people are confused with that, too.
I am just curious, why there wasn't a better solution to such a
problem? gcc wants me to add the dummy output var for that, and
googling reveals some discussion that a better syntax was simply
not found. But IMHO, allowing "&" modifier in the input list is
the most natural way of expressing that the input is being
clobbered after the value is taken.

> Assuming you actually want the output, it should be:
No, what I really want, is an input. I.e. I want to put the
input in %%ebx. But then, after I already used it, I want to
re-use %%ebx in an asm code. And here's the gotcha: re-using
%%ebx also alters the input operand, but not always - that
depends on an optimization level. I find that counter-intuitive,
hence the questions.

Re: clobbering input args in inline asm

[Andrew Haley]

Stas Sergeev writes:

 > Andrew Haley wrote:
 > > The clobber list is for physical register names such as "ebx", not for
 > > operands.
 > Yes, that's why my question was not "why it still
 > doesn't work", but rather "what does the "0" mean, when
 > put in the clobber list?"

It means nothing.

 > gcc accepts it there, and I wasn't able to find anywhere in the
 > docs, what does it mean.

 > > This is wrong: you're clobbering one of the inputs without telling
 > > gcc.
 > Yes, but the problem is, the way to tell this to gcc
 > looks very strange to me. Here's only what I've been
 > able to find in the docs:
 > ---
 > There is no way for you to specify that an input
 > operand is modified without also specifying it as an output
 > operand.  Note that if all the output operands you specify are for this
 > purpose (and hence unused), you will then also need to specify
 > |volatile| for the |asm| construct, as described below, to
 > prevent GCC from deleting the |asm| statement as unused.

 > A quick googling shows many people are confused with that, too.  I
 > am just curious, why there wasn't a better solution to such a
 > problem? gcc wants me to add the dummy output var for that, and
 > googling reveals some discussion that a better syntax was simply
 > not found. But IMHO, allowing "&" modifier in the input list is the
 > most natural way of expressing that the input is being clobbered
 > after the value is taken.
 > 
 > > Assuming you actually want the output, it should be:
 > No, what I really want, is an input. I.e. I want to put the
 > input in %%ebx. But then, after I already used it, I want to
 > re-use %%ebx in an asm code. And here's the gotcha: re-using
 > %%ebx also alters the input operand, but not always - that
 > depends on an optimization level. I find that counter-intuitive,
 > hence the questions.

You want to use something as an input operand, and you want to clobber
it as well.  OK, I get the idea.

But the docs already explain that "there is no way for you to specify
that an input operand is modified without also specifying it as an
output operand."  So, you already know this, but you want to know why.

I suspect the simplest answer you're likely to get is that the reload
pass is complicated enough already without adding yet another operand
attribute, especially one which adds very little capability.

Andrew.

Re: clobbering input args in inline asm

[Stas Sergeev]

Hi.

Andrew Haley wrote:
>> doesn't work", but rather "what does the "0" mean, when
>> put in the clobber list?"
> It means nothing.
Well, the real reason why I wrote the message, was
that I suspected the bug. When I put "0" in clobber, gcc
eats it *unless* I have "a" in input list - then it complains.
Any other register class in input with "0" in clobber seem to
be accepted without a complain.
That looked very suspicious, but of course I couldn't fill up
the bug entry without knowing what exactly "0" means in the
clobber list. Now if it means *nothing*, then the bug is definitely
not there. I just wanted to be sure. :)

> So, you already know this, but you want to know why.
Exactly, coupled with the fact that this thread:
http://lkml.org/lkml/1998/4/10/16
suggests that the better syntax was simply not found, which
itself looks very strange.

> I suspect the simplest answer you're likely to get
If at all. ;) Thanks for your answers.

Re: clobbering input args in inline asm

[Andrew Haley]

Stas Sergeev writes:
 > Hi.
 > 
 > Andrew Haley wrote:
 > >> doesn't work", but rather "what does the "0" mean, when
 > >> put in the clobber list?"
 > > It means nothing.
 > Well, the real reason why I wrote the message, was
 > that I suspected the bug. When I put "0" in clobber, gcc
 > eats it *unless* I have "a" in input list - then it complains.
 > Any other register class in input with "0" in clobber seem to
 > be accepted without a complain.
 > That looked very suspicious, but of course I couldn't fill up
 > the bug entry without knowing what exactly "0" means in the
 > clobber list. Now if it means *nothing*, then the bug is definitely
 > not there. I just wanted to be sure. :)

The real thing going on here is that gcc exposes some of its internal
structures in extended asm.  That's what all this clobber stuff is,
register constraints, and so on.  It's all part of gcc's machine
description.

If you *really* want to know how RTL templates in the machine
description are formed, see 13.4, RTL Template, in gccint.info.  This
will tell you about the different forms a clobber can take.  And then
you'll see what's really going on.  This might be more than you really
want to know.  :-)

Andrew.