KVM Archive on lore.kernel.org
 help / color / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Greg Kurz" <groug@kaod.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org, Juan Quintela <quintela@redhat.com>,
	qemu-ppc@nongnu.org, Marcelo Tosatti <mtosatti@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-arm@nongnu.org, Alistair Francis <alistair.francis@wdc.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 04/15] hw/ppc/spapr_rtas: Restrict variables scope to single switch case
Date: Fri, 10 Jan 2020 13:18:42 -0600
Message-ID: <6ad8e693-813a-26ea-73f8-319d440de1e3@redhat.com> (raw)
In-Reply-To: <20200110105055.3e72ddf4@bahia.lan>

On 1/10/20 3:50 AM, Greg Kurz wrote:

>>> I guess a decent compiler can be smart enough detect that the initialization
>>> isn't needed outside of the RTAS_SYSPARM_SPLPAR_CHARACTERISTICS branch...
>>> Anyway, reducing scope isn't bad. The only hitch I could see is that some
>>> people do prefer to have all variables declared upfront, but there's a nested
>>> param_val variable already so I guess it's okay.
>>
>> I don't want to outsmart compilers :)

Or conversely play the game of which compilers will warn about an 
atypical construct.

>>
>> The MACHINE() macro is not a simple cast, it does object introspection
>> with OBJECT_CHECK(), thus is not free. Since
> 
> Sure, I understand the motivation in avoiding an unneeded call
> to calling object_dynamic_cast_assert().
> 
>> object_dynamic_cast_assert() argument is not const, I'm not sure the
>> compiler can remove the call.
>>
> 
> Not remove the call, but delay it to the branch that uses it,
> ie. parameter == RTAS_SYSPARM_SPLPAR_CHARACTERISTICS.
> 
>> Richard, Eric, do you know?
>>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> ---
>>>>    hw/ppc/spapr_rtas.c | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
>>>> index 6f06e9d7fe..7237e5ebf2 100644
>>>> --- a/hw/ppc/spapr_rtas.c
>>>> +++ b/hw/ppc/spapr_rtas.c
>>>> @@ -267,8 +267,6 @@ static void rtas_ibm_get_system_parameter(PowerPCCPU *cpu,
>>>>                                              uint32_t nret, target_ulong rets)
>>>>    {
>>>>        PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
>>>> -    MachineState *ms = MACHINE(spapr);
>>>> -    unsigned int max_cpus = ms->smp.max_cpus;
>>>>        target_ulong parameter = rtas_ld(args, 0);
>>>>        target_ulong buffer = rtas_ld(args, 1);
>>>>        target_ulong length = rtas_ld(args, 2);
>>>> @@ -276,6 +274,8 @@ static void rtas_ibm_get_system_parameter(PowerPCCPU *cpu,
>>>>    
>>>>        switch (parameter) {
>>>>        case RTAS_SYSPARM_SPLPAR_CHARACTERISTICS: {
>>>> +        MachineState *ms = MACHINE(spapr);
>>>> +        unsigned int max_cpus = ms->smp.max_cpus;

Declaring an initializer inside a switch statement can trigger warnings 
under some compilation scenarios (particularly if the variable is 
referenced outside of the scope where it was introduced).  But here, you 
are using 'case label: { ...' to create a scope, which presumably ends 
before the next case label, and is thus not going to trigger compiler 
warnings.

An alternative is indeed leaving the declaration up front but deferring 
the (possibly expensive) initializer to the case label that needs it:

MachineState *ms;
switch (parameter) {
case ...:
   ms = MACHINE(spapr);

and done that way, you might not even need the extra {} behind the case 
label (I didn't read the file to see if there is already some other 
reason for having introduced that sub-scope).

As for whether compilers are smart enough to defer non-trivial 
initialization to the one case label that uses the variable, I wouldn't 
count on it.  If the non-trivial initialization includes a function call 
(which the MACHINE() macro does), it's much harder to prove whether that 
function call has side effects that may be needed prior to the switch 
statement.  So limiting the scope of the initialization (whether by 
dropping the declaration, or just deferring the call) DOES make sense.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


  reply index

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:21 [PATCH 00/15] Replace current_machine by qdev_get_machine() Philippe Mathieu-Daudé
2020-01-09 15:21 ` [PATCH 01/15] target/arm/kvm: Use CPUState::kvm_state in kvm_arm_pmu_supported() Philippe Mathieu-Daudé
2020-01-10  9:59   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 02/15] hw/ppc/spapr_rtas: Use local MachineState variable Philippe Mathieu-Daudé
2020-01-09 17:13   ` Greg Kurz
2020-01-13  1:11   ` David Gibson
2020-01-09 15:21 ` [PATCH 03/15] hw/ppc/spapr_rtas: Access MachineState via SpaprMachineState argument Philippe Mathieu-Daudé
2020-01-09 17:13   ` Greg Kurz
2020-01-13  1:11   ` David Gibson
2020-01-09 15:21 ` [PATCH 04/15] hw/ppc/spapr_rtas: Restrict variables scope to single switch case Philippe Mathieu-Daudé
2020-01-09 17:43   ` Greg Kurz
2020-01-10  9:34     ` Philippe Mathieu-Daudé
2020-01-10  9:50       ` Greg Kurz
2020-01-10 19:18         ` Eric Blake [this message]
2020-01-13  7:16         ` David Gibson
2020-01-09 15:21 ` [PATCH 05/15] device-hotplug: Replace current_machine by qdev_get_machine() Philippe Mathieu-Daudé
2020-01-12  9:42   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 06/15] migration/savevm: " Philippe Mathieu-Daudé
2020-01-09 15:52   ` Dr. David Alan Gilbert
2020-01-12  9:43   ` Alistair Francis
2020-01-14 13:27   ` Juan Quintela
2020-01-09 15:21 ` [PATCH 07/15] hw/core/machine-qmp-cmds: " Philippe Mathieu-Daudé
2020-01-12  9:44   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 08/15] target/arm/monitor: " Philippe Mathieu-Daudé
2020-01-12  9:47   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 09/15] device_tree: " Philippe Mathieu-Daudé
2020-01-12  9:47   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 10/15] memory: " Philippe Mathieu-Daudé
2020-01-12  9:48   ` Alistair Francis
2020-01-12 13:45     ` Philippe Mathieu-Daudé
2020-01-14  2:02       ` Alistair Francis
2020-01-09 15:21 ` [PATCH 11/15] exec: " Philippe Mathieu-Daudé
2020-01-14  1:57   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 12/15] accel: Introduce the current_accel() method Philippe Mathieu-Daudé
2020-01-14  1:59   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 13/15] accel: Replace current_machine->accelerator by " Philippe Mathieu-Daudé
2020-01-14  1:58   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 14/15] accel/accel: Replace current_machine by qdev_get_machine() Philippe Mathieu-Daudé
2020-01-14  1:59   ` Alistair Francis
2020-01-09 15:21 ` [PATCH 15/15] vl: Make current_machine a local variable Philippe Mathieu-Daudé
2020-01-14  2:00   ` Alistair Francis
2020-01-21  8:59 ` [PATCH 00/15] Replace current_machine by qdev_get_machine() Markus Armbruster

Reply instructions:

You may reply publically 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=6ad8e693-813a-26ea-73f8-319d440de1e3@redhat.com \
    --to=eblake@redhat.com \
    --cc=alistair.francis@wdc.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=groug@kaod.org \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=quintela@redhat.com \
    --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

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git