From: "H. Peter Anvin" <hpa@zytor.com>
To: Kyle Moffett <kyle@moffetthome.net>
Cc: "Duncan Sands" <baldrick@free.fr>,
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 17:56:00 -0800 [thread overview]
Message-ID: <497FBB30.3020804@zytor.com> (raw)
In-Reply-To: <f73f7ab80901271745o4e426baew8a1f67dbacbe1aef@mail.gmail.com>
Kyle Moffett wrote:
>
> Actually, PPC64 boxes basically don't care... the usable GPRs are all
> either 32-bit (for PPC32) or 64-bit (for PPC64), the <=32-bit
> instructions are identical across both, they just
> truncate/sign-extend/etc based on the lower 32-bits of the register.
> Also, you would only do a right-shift if you were going all the way
> out to memory as 64-bit and all the way back in as 32-bit... within a
> single register it's kept coherent.
>
Think about a 64-bit integer on ppc32. It will by necessity kept in two
registers. On gcc I believe it will always be a consecutive pair of
registers (AFAIK that's a hard-coded assumption in gcc, with the result
that gcc has a nonstandard internal register numbering for x86 since the
commonly used dx:ax pair is actually registers 2:0 in the hardware
numbering.)
> Structs are basically irrelevant for inline ASM as you can't pass a
> struct to one... you can only pass the *address* of a struct, which is
> always pointer-sized.
Right, of course.
> I think that really the only sane solution (which is hopefully what
> GCC does) for integer types is to use a register the same size as the
> larger of the two integers. Then you copy the value to/from the
> smaller register (or just mask it on PPC64-alike architectures) before
> or after the inline ASM.
Pretty much. Then you can do conventional copy propagation and
elimination after expanding subregisters to get rid of the extra ops in
the common case.
-hpa
next prev parent reply other threads:[~2009-01-28 1:56 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
2009-01-28 1:45 ` Kyle Moffett
2009-01-28 1:56 ` H. Peter Anvin [this message]
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=497FBB30.3020804@zytor.com \
--to=hpa@zytor.com \
--cc=baldrick@free.fr \
--cc=edwintorok@gmail.com \
--cc=kyle@moffetthome.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox