From: Richard Henderson <rth@twiddle.net>
To: Laurent Desnogues <laurent.desnogues@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Blue Swirl" <blauwirbel@gmail.com>,
"Paul Brook" <paul@codesourcery.com>,
"Lluís Vilanova" <vilanova@ac.upc.edu>,
"Artyom Tarasenko" <atar4qemu@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion
Date: Thu, 29 Mar 2012 12:28:42 -0400 [thread overview]
Message-ID: <4F748DBA.2040700@twiddle.net> (raw)
In-Reply-To: <CABoDooOi-5KoVAmKOZ1LAtMGbBe=PmsC3o-g1bBkb4GTO-4dLw@mail.gmail.com>
On 03/29/2012 11:42 AM, Laurent Desnogues wrote:
> That will indeed probably make the real problem, which is that
> this patch increases the size of generated code, less obvious
> on small benchmarks that don't put pressure on instruction
> cache. But the fact is that generated code is larger and will
> have to execute more instructions, so no matter what you do,
> this will have an impact on speed.
While this is true, the benefit of using a more standard calling
convention on reliability and debug-ability is enormous.
Consider the i686 host, where we currently obscond with EBP.
While I'm not aware of any current problems with -O0 or spill
failures under optimization, it's not inconceivable.
Consider sparc-linux host, where we have *no* call-saved global
register at all, and (currently) try very hard to use a call-
clobbered global register, with occasionally disastrous results.
See the patch set I posted recently where I give up on this entirely
and make sparc use a TLS variable instead of a hard register at all.
This regresses the Sparc host on speed for a progression in reliability.
The conversion to explicit env arguments fixes essentially all of
the speed regression since we then receive ENV in %o0 instead of
having to read from TLS.
r~
prev parent reply other threads:[~2012-03-29 16:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-24 18:58 [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion Blue Swirl
2012-03-25 22:29 ` Richard Henderson
2012-03-26 11:52 ` Peter Maydell
2012-03-26 12:46 ` Lluís Vilanova
2012-03-26 12:48 ` Andreas Färber
2012-03-26 13:05 ` Paul Brook
2012-03-26 17:02 ` Blue Swirl
2012-03-26 17:59 ` Lluís Vilanova
2012-03-27 13:40 ` Laurent Desnogues
2012-03-27 16:48 ` Blue Swirl
2012-03-27 17:01 ` Laurent Desnogues
2012-03-27 19:59 ` Artyom Tarasenko
2012-03-29 15:42 ` Laurent Desnogues
2012-03-29 16:28 ` Richard Henderson [this message]
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=4F748DBA.2040700@twiddle.net \
--to=rth@twiddle.net \
--cc=atar4qemu@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=laurent.desnogues@gmail.com \
--cc=paul@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=vilanova@ac.upc.edu \
/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.