From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19900 invoked by alias); 1 Dec 2009 11:29:07 -0000 Received: (qmail 19892 invoked by uid 22791); 1 Dec 2009 11:29:07 -0000 X-SWARE-Spam-Status: No, hits=-8.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Dec 2009 11:29:02 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 9C2AC5362F; Tue, 1 Dec 2009 12:29:00 +0100 (CET) Date: Tue, 01 Dec 2009 11:33:00 -0000 From: Martin Jambor To: Richard Guenther Cc: GCC Patches , Jan Hubicka Subject: Re: [PATCH] Reorder fields in struct cgraph_edge et al Message-ID: <20091201112900.GB4389@virgil.suse.cz> Mail-Followup-To: Richard Guenther , GCC Patches , Jan Hubicka References: <20091130204143.GF12510@virgil.suse.cz> <20091201105627.GA4389@virgil.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00045.txt.bz2 On Tue, Dec 01, 2009 at 12:04:58PM +0100, Richard Guenther wrote: > On Tue, 1 Dec 2009, Martin Jambor wrote: > > > Hi, > > > > On Tue, Dec 01, 2009 at 10:46:33AM +0100, Richard Guenther wrote: > > > > > > you now have introduced 32bit padding here ... > > > > > > > No, even on i386 gcov_type is 64 bit. I have just double checked. > > I have committed the patch as it was per Honza's approval. > > But what's the point moving it first, even before the next pointer? > The next pointer is accessed during traversing, possibly quite more > frequent than count. > Well, after I saw how misaligned everything was (and so how little we, including myself, sometimes care about this when we add stuff), I thought that reordering the fields according to their size was the safest way of preventing someone from inadvertently reintroducing the padding. Even more so because nobody seems to really remember how big gcov_type actually is (I also had to ask Honza, probably not for the first time). Having said that, putting it after next_callee with a comment about this is probably also rather safe (as opposed to anything lower than that). I can do that if you want. Martin > Richard. > > > > > Martin > > > > > > > Ok with that chagnes. > > > > > > Richard. > > > > > > > /* Linked list's next */ > > > > struct ipa_param_call_note *next; > > > > /* Statement that contains the call to the parameter above. */ > > > > @@ -147,13 +149,11 @@ struct ipa_param_call_note > > > > unsigned int lto_stmt_uid; > > > > /* Index of the parameter that is called. */ > > > > int formal_id; > > > > - /* Expected number of executions: calculated in profile.c. */ > > > > - gcov_type count; > > > > /* Expected frequency of executions within the function. see cgraph_edge in > > > > cgraph.h for more on this. */ > > > > int frequency; > > > > /* Depth of loop nest, 1 means no loop nest. */ > > > > - int loop_nest; > > > > + unsigned short int loop_nest; > > > > /* Set when we have already found the target to be a compile time constant > > > > and turned this into an edge or when the note was found unusable for some > > > > reason. */ > > > > > > > > > > > > > > -- > Richard Guenther > Novell / SUSE Labs > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex