From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZG2xI-0005ls-8i for qemu-devel@nongnu.org; Fri, 17 Jul 2015 06:33:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZG2xH-0005j7-CW for qemu-devel@nongnu.org; Fri, 17 Jul 2015 06:33:24 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:33811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZG2xH-0005io-6I for qemu-devel@nongnu.org; Fri, 17 Jul 2015 06:33:23 -0400 Date: Fri, 17 Jul 2015 12:33:21 +0200 From: Aurelien Jarno Message-ID: <20150717103321.GA14985@aurel32.net> References: <1436958199-5181-1-git-send-email-aurelien@aurel32.net> <1436958199-5181-9-git-send-email-aurelien@aurel32.net> <55A8A2CB.70001@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A8A2CB.70001@twiddle.net> Subject: Re: [Qemu-devel] [PATCH RFC 8/9] tcg/optimize: do not simplify size changing moves List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Paolo Bonzini , qemu-devel@nongnu.org On 2015-07-17 07:38, Richard Henderson wrote: > On 07/15/2015 12:03 PM, Aurelien Jarno wrote: > >Now that we have real size changing ops, we don't need to marked high > >bits of the destination as garbage. The goal of the optimizer is to > >predict the value of the temps (and not of the registers) and do > >simplifications when possible. The problem there is therefore not the > >fact that those bits are not counted as garbage, but that a size > >changing op is replaced by a move. > > > >This patch is basically a revert of 24666baf, including the changes that > >have been made since then. > > > >Cc: Paolo Bonzini > >Cc: Richard Henderson > >Signed-off-by: Aurelien Jarno > > What we're missing here is whether the omitted size changing op is extu or > exts. Mask should be extended to match. Which means keeping most of this > code. I am afraid your correct. Unfortunately one of my goal is to remove this part in the optimizer, as I need that in a patch series I am preparing. I have also tried to check the temp type directly from the optimizer (it is accessible), but it has some performance impact. Propagating the extu/exts as real opcode means propagating the information about size changing up to the optimizer or the register allocator, without having to recreate it from other available information. For now I do wonder if we shouldn't get the size changing extu/exts mandatory instead of reusing the 64-bit only version. This doesn't change the generated code, at least on x86. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net