Re: clobbering input args in inline asm

[Andrew Haley <aph at redhat dot com>]

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.