From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TERu1-0006Ds-Tt for qemu-devel@nongnu.org; Wed, 19 Sep 2012 17:33:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TERu0-0006X6-Ru for qemu-devel@nongnu.org; Wed, 19 Sep 2012 17:33:49 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:54529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TERu0-0006X2-LC for qemu-devel@nongnu.org; Wed, 19 Sep 2012 17:33:48 -0400 Received: by pbbrp12 with SMTP id rp12so3425207pbb.4 for ; Wed, 19 Sep 2012 14:33:47 -0700 (PDT) Sender: Richard Henderson Message-ID: <505A3A3A.5070002@twiddle.net> Date: Wed, 19 Sep 2012 14:33:46 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1348084823-18277-1-git-send-email-aurelien@aurel32.net> <1348084823-18277-3-git-send-email-aurelien@aurel32.net> In-Reply-To: <1348084823-18277-3-git-send-email-aurelien@aurel32.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/9] tcg/optimizer: check types in copy propagation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org On 09/19/2012 01:00 PM, Aurelien Jarno wrote: > The copy propagation doesn't check the types of the temps during copy > propagation. However TCG is using the mov_i32 for the i64 to i32 > conversion and thus the two are not equivalent. > > With this patch tcg_opt_gen_mov() doesn't consider two temps with > different types as copies anymore. > > So far it seems the optimization was not aggressive enough to trigger > this bug, but it will be triggered later in this series once the copy > propagation is improved. Exactly where/how does this manifest as problematic? We do this mov_i32 trick from i64->i32 when we're truncating. Given that we're not (yet) targeting mips64 and having to maintain 32-bit sign-extended quantities, I can't see how that would matter. We do the i32->i64 trick immediately before a proper extension. In either case I can't see how plain copy propagation should matter until some other operation is involved. So, do we have some other data propagation bug that is being masked here? r~