From: Aurelien Jarno <aurelien@aurel32.net>
To: Richard Henderson <rth@twiddle.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 00/13] tcg/sparc v8plus code generation
Date: Fri, 17 Jul 2015 15:42:47 +0200 [thread overview]
Message-ID: <20150717134247.GA4343@aurel32.net> (raw)
In-Reply-To: <20150717102350.GA15281@aurel32.net>
On 2015-07-17 12:23, Aurelien Jarno wrote:
> On 2015-07-16 22:29, Richard Henderson wrote:
> > On 07/15/2015 09:54 PM, Aurelien Jarno wrote:
> > >While I understand why we need the new trunc_shr_i32 opcode for MIPS64
> > >(the 32-bit values must be kept sign-extended), I currently fail to
> > >see why it is needed for SPARC.
> >
> > As far as I recall, it improves code for extracting high parts of 64-bit
> > quantities. Without this, we wind up with a 64-bit shift, requiring a
> > 64-bit temp register, followed by the "real" truncate which can copy the
> > data to a 32-bit destination register.
>
> Ok, I understand the use case now. So it's not for correctness, but
> rather to generate more optimized code.
OTOH, it means that we always have to go through a 32-bit register first
when truncating a 64-bit value.
I mean we gain in the following case:
shr_i64 t64, t64, i
trunc_i64_i32 t32, t64
...
But we lose in the following case:
trunc_i64_i32 t32, t64
neg t32, t32
...
Overall I guess the advantages far outweigh the disadvantages.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
next prev parent reply other threads:[~2015-07-17 13:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1398369715-16102-1-git-send-email-rth@twiddle.net>
2015-07-15 20:54 ` [Qemu-devel] [PATCH v2 00/13] tcg/sparc v8plus code generation Aurelien Jarno
2015-07-16 21:29 ` Richard Henderson
2015-07-17 10:23 ` Aurelien Jarno
2015-07-17 13:42 ` Aurelien Jarno [this message]
2015-07-18 7:21 ` Richard Henderson
2015-07-18 21:18 ` Aurelien Jarno
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=20150717134247.GA4343@aurel32.net \
--to=aurelien@aurel32.net \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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;
as well as URLs for NNTP newsgroup(s).