From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaDJV-0003Tx-W6 for qemu-devel@nongnu.org; Mon, 23 Mar 2015 21:07:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaDJU-0007Ws-Pc for qemu-devel@nongnu.org; Mon, 23 Mar 2015 21:07:25 -0400 Sender: Richard Henderson Message-ID: <5510B8C4.1050302@twiddle.net> Date: Mon, 23 Mar 2015 18:07:16 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1426919232-20813-1-git-send-email-cota@braap.org> <551088CF.1050001@weilnetz.de> In-Reply-To: <551088CF.1050001@weilnetz.de> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tcg: pack TCGTemp to reduce size by 8 bytes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil , "Emilio G. Cota" , qemu-devel@nongnu.org Cc: qemu-trivial@nongnu.org On 03/23/2015 02:42 PM, Stefan Weil wrote: > Further optimizations are possible. TCGTemp can be reduced to 32 bytes as the > output > of pahole shows: > > struct TCGTemp { > TCGTempVal val_type:8; /* 0:24 4 */ Need only be 2 bits. > unsigned int reg:8; /* 0:16 4 */ > unsigned int mem_reg:8; /* 0: 8 4 */ Need only be 6 (ia64) bits, but an aligned 8-bit slot probably performs best. > > /* Bitfield combined with next fields */ > > _Bool fixed_reg:1; /* 3: 7 1 */ > _Bool mem_coherent:1; /* 3: 6 1 */ > _Bool mem_allocated:1; /* 3: 5 1 */ > _Bool temp_local:1; /* 3: 4 1 */ > _Bool temp_allocated:1; /* 3: 3 1 */ > > /* XXX 3 bits hole, try to pack */ > > TCGType base_type:16; /* 4:16 4 */ > TCGType type:16; /* 4: 0 4 */ Need only be 1 bit, honestly, but 2 bits might be easier to arrange. Anyway, you're down to 23 bits from the word, or 16 bytes on a 32-bit host. It's no better than the 32 bytes you got for a 64-bit host though. > tcg_target_long val; /* 8 8 */ > intptr_t mem_offset; /* 16 8 */ > const char * name; /* 24 8 */ > > /* size: 32, cachelines: 1, members: 13 */ > /* bit holes: 1, sum bit holes: 3 bits */ > /* last cacheline: 32 bytes */ > }; > > Here I used a new enum type for val_type and reduced some values to 8 or 16 bit. > I also put the two most often used values at the beginning, so they can be > addressed without or with a small offset ("often" in the code, no runtime > data available). > > Are such optimizations useful? Yes, I think so. Especially because of the rather large arrays we build. r~