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 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.