lkml.org 
[lkml]   [2009]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [LLVMdev] inline asm semantics: output constraint width smaller than input
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



\
 
 \ /
  Last update: 2009-01-27 22:29    [W:0.060 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site