WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] cpufreq.c: shut up compiler about cpufreq_dom

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] cpufreq.c: shut up compiler about cpufreq_dom
From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Date: Fri, 31 Oct 2008 09:33:51 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 30 Oct 2008 18:34:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18697.32691.152385.432371@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <18696.37682.162183.607991@xxxxxxxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC2140C865C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18697.32691.152385.432371@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ack6cshlMXjjWhbRRg+DClGQSAGlpwAheiog
Thread-topic: [Xen-devel] [PATCH] cpufreq.c: shut up compiler about cpufreq_dom
Ian Jackson wrote:
> Liu, Jinsong writes ("RE: [Xen-devel] [PATCH] cpufreq.c: shut up
>> What's the advantage of the above coding style? seems it saved a
>> flag but add 1 more jump.
> 
> It's clearer, and the compiler can see what's going on.
> 
> There isn't another jump `as written', since `break' is a jump too.
> Whether there is another jump after the compiler is done with it
> depends on a lot of factors, but generally I would expect the compiler
> to do a better job when information about the program's possible
> behaviours is represented directly in the control flow than when it is
> stored in a flag variable.
> 
> For example, often the allocation of a new structure can be done
> directly at the point where we fall out of the loop, eg:
>>>        for (...) { cpufreq_dom = dom; if (...) goto
>>> cpufreq_dom_found; } 
>            cpufreq_dom = xmalloc(...);  cpufreq_dom->contents =
> value; ... 
>>>      cpufreq_dom_found:
> 
> Ian.

Thanks a lot!

Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel