From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvVK9-0002Ap-Sp for qemu-devel@nongnu.org; Thu, 21 May 2015 14:36:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvVK8-0007Jg-U0 for qemu-devel@nongnu.org; Thu, 21 May 2015 14:36:05 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:101::1]:51231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvVK8-0007Ix-OO for qemu-devel@nongnu.org; Thu, 21 May 2015 14:36:04 -0400 Date: Thu, 21 May 2015 20:35:54 +0200 From: Aurelien Jarno Message-ID: <20150521183554.GA8235@aurel32.net> References: <1432031208-20020-1-git-send-email-aurelien@aurel32.net> <555B4CAC.30805@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555B4CAC.30805@twiddle.net> Subject: Re: [Qemu-devel] [PATCH] tcg: fix dead computation for repeated input arguments List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On 2015-05-19 07:46, Richard Henderson wrote: > On 05/19/2015 03:26 AM, Aurelien Jarno wrote: > > @@ -1522,6 +1522,9 @@ static void tcg_liveness_analysis(TCGContext *s) > > if (dead_temps[arg]) { > > dead_args |= (1 << i); > > } > > + } > > + for (i = nb_oargs; i < nb_oargs + nb_iargs; i++) { > > + arg = args[i]; > > dead_temps[arg] = 0; > > } > > s->op_dead_args[oi] = dead_args; > > How about another line of commentary for each loop? > > Something like > > /* Record arguments that die in this opcode. */ > > for the first and > > /* Input arguments are live for preceeding opcodes. */ > > for the second. Good point. > As for the same loop for calls, you're right that it may well cause us to do a > tiny bit of redundant work, but nothing else bad will happen. We'll enter > temp_dead more times than necessary. I'm always skeptical about knowingly > giving a compiler bad information though. You tend to not know how data is > going to be used in future, and *then* get bad results. You are correct. Anyway I don't think it'll make a big difference in performance. I'll send a new version of the patch. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net