Re: [LLVMdev] inline asm semantics: output constraint width smaller than input

[H. Peter Anvin]

Duncan Sands wrote:
> Hi,
>
> > If yes then this doesnt look all that bad or invasive at first sight (if 
> > the put_user() workaround can be expressed in a cleaner way), but in any 
> > case it would be nice to hear an LLVM person's opinion about roughly when 
> > this is going to be solved in LLVM itself.
>
> one thing that seems to be clear to everyone except me is... what are the
> semantics supposed to be?  [My understanding is that what is being discussed
> is when you have an asm with a register as input and output, but with integer
> types of different width for the input and output, but I saw some mention of
> struct types in this thread...].  Presumably this is something obvious, but
> it would be good to have someone spell it out in small words that even someone
> like me can understand :)

I don't know about struct types, but the situation I'm talking about is 
assembly statements of the form:

asm("foo" : "=r" (bar) : "0" (baz));

Here, "bar" and "baz" are constrained to be in the same hardware 
register (from the "0" constraint in "baz").  The types of "bar" and 
"baz" are otherwise unrelated.

I assume the difficulty here comes from how this needs to be handled 
from the point of view of the register allocator.  If both types fit 
inside a single allocatable hardware register, the issue is trivial; 
"bar" and "baz" form a single logical register for the purpose of 
register allocation.

However, things get a bit ugly in the case of different widths that 
affect individually scheduled registers, like 32- and 64-bit types on a 
32-bit machine.  Consider the case above where "bar" is a 64-bit type 
and "baz" is a 32-bit type, then you functionally have, at least on x86:

	uint64_t tmp = bar;
	asm("foo" : "+r" (tmp));
	baz = (uint32_t)tmp;

One could possibly argue that the latter case should be
"baz = (uint32_t)(tmp >> 32);" on a bigendian machine... since this is a 
gcc syntax it probably should be "whatever gcc does" in that case, as 
opposed to what might make sense.

(I'm afraid I don't have a bigendian box readily available at the 
moment, so I can't test it out to see what gcc does.  I have a powerpc 
machine, but it's at home and turned off.)

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/