From: Paolo Bonzini <pbonzini@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
aliguori@us.ibm.com, qemu-devel@nongnu.org,
Alexander Graf <agraf@suse.de>, PowerPC <qemu-ppc@nongnu.org>,
aurelien@aurel32.net
Subject: Re: [Qemu-devel] [PATCH for-1.5?] target-ppc: Drop unnecessary dynamic cast in ppc_env_get_cpu()
Date: Fri, 10 May 2013 17:07:04 +0200 [thread overview]
Message-ID: <518D0D18.1060408@redhat.com> (raw)
In-Reply-To: <518D0869.9020009@suse.de>
Il 10/05/2013 16:47, Andreas Färber ha scritto:
> Am 10.05.2013 16:42, schrieb Peter Maydell:
>> On 10 May 2013 15:39, Andreas Färber <afaerber@suse.de> wrote:
>>> A transition from CPUPPCState to PowerPCCPU can be considered safe,
>>> just like PowerPCCPU::env access in the opposite direction.
>>>
>>> This should slightly improve interrupt performance.
>>
>>> static inline PowerPCCPU *ppc_env_get_cpu(CPUPPCState *env)
>>> {
>>> - return POWERPC_CPU(container_of(env, PowerPCCPU, env));
>>> + return container_of(env, PowerPCCPU, env);
>>> }
This doesn't fix the same in problem in ENV_GET_CPU. It would fix half
of the problem, but not the other half.
I don't want to think in advance of what casts are in hot paths. The
less I think about such useless details, the less bug I will put in my
code. I _want_ to code defensively (and have gdb pinpoint problems fast
while developing), I just don't want that to come at a performance cost
for users.
Algorithmic invariants are what you need to assert against. As far as
type-safety is concerned, people are used to SIGSEGVs and it doesn't
change anything to them if they get SIGABRTs instead. *If* the
type-safety is a major concern, at least patch 4 of my series should be
a no brainer. And with the tracing support introduced by patch 5, the
price of having a little less type-safety should be more than acceptable.
>> So if this is worthwhile shouldn't we be doing it for
>> all our CPUs?
>
> I thought ppc were the exception, but you're right there's 15
> occurrences remaining, i.e. all targets do it that way currently.
>
> Don't have time right now for large cross-tree cleanups, so feel free to
> profile with and without this patch.
Well, we have a week to get this in.
Paolo
next prev parent reply other threads:[~2013-05-10 15:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-10 14:39 [Qemu-devel] [PATCH for-1.5?] target-ppc: Drop unnecessary dynamic cast in ppc_env_get_cpu() Andreas Färber
2013-05-10 14:42 ` Peter Maydell
2013-05-10 14:47 ` Andreas Färber
2013-05-10 15:07 ` Paolo Bonzini [this message]
2013-05-10 15:02 ` Anthony Liguori
2013-05-10 15:06 ` Anthony Liguori
2013-05-10 15:08 ` Paolo Bonzini
2013-05-10 15:54 ` Andreas Färber
[not found] ` <518D10E3.4080001@suse.de>
[not found] ` <14CF0363-E558-4387-A401-14C940131BDB@suse.de>
2013-05-10 16:14 ` Andreas Färber
2013-05-10 16:20 ` Peter Maydell
2013-05-10 16:40 ` Andreas Färber
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=518D0D18.1060408@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=aurelien@aurel32.net \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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).