From: "H. Peter Anvin" <hpa@zytor.com>
To: Duncan Sands <baldrick@free.fr>
Cc: llvmdev@cs.uiuc.edu, "Ingo Molnar" <mingo@elte.hu>,
"Török Edwin" <edwintorok@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [LLVMdev] inline asm semantics: output constraint width smaller than input
Date: Tue, 27 Jan 2009 13:25:18 -0800 [thread overview]
Message-ID: <497F7BBE.4070500@zytor.com> (raw)
In-Reply-To: <200901272042.57272.baldrick@free.fr>
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
next prev parent reply other threads:[~2009-01-27 21:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-23 17:57 inline asm semantics: output constraint width smaller than input Török Edwin
2009-01-23 18:17 ` Ingo Molnar
2009-01-23 18:21 ` H. Peter Anvin
2009-01-23 18:27 ` Török Edwin
2009-01-23 18:30 ` Ingo Molnar
2009-01-23 18:52 ` Török Edwin
2009-01-23 20:42 ` Török Edwin
2009-01-24 16:23 ` Török Edwin
2009-01-24 17:27 ` Ingo Molnar
2009-01-24 18:57 ` Török Edwin
2009-01-24 21:25 ` [LLVMdev] " Mike Stump
2009-01-24 19:23 ` Chris Lattner
2009-01-24 21:10 ` H. Peter Anvin
2009-01-27 19:42 ` Duncan Sands
2009-01-27 21:25 ` H. Peter Anvin [this message]
2009-01-28 1:45 ` Kyle Moffett
2009-01-28 1:56 ` H. Peter Anvin
2009-01-28 13:28 ` Kyle Moffett
2009-01-28 17:29 ` H. Peter Anvin
2009-01-28 19:27 ` Kyle Moffett
2009-01-28 20:59 ` H. Peter Anvin
2009-01-24 20:07 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=497F7BBE.4070500@zytor.com \
--to=hpa@zytor.com \
--cc=baldrick@free.fr \
--cc=edwintorok@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvmdev@cs.uiuc.edu \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.