From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23956 invoked by alias); 6 Jan 2013 16:23:09 -0000 Received: (qmail 23936 invoked by uid 22791); 6 Jan 2013 16:23:06 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_VZ,TW_ZJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 06 Jan 2013 16:22:58 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r06GMuYn010958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Jan 2013 11:22:56 -0500 Received: from zalov.redhat.com (vpn1-6-187.ams2.redhat.com [10.36.6.187]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r06GMsKE032035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2013 11:22:55 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r06GMrIQ031700; Sun, 6 Jan 2013 17:22:53 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r06GMqQm031699; Sun, 6 Jan 2013 17:22:52 +0100 Date: Sun, 06 Jan 2013 16:23:00 -0000 From: Jakub Jelinek To: Uros Bizjak , Paolo Bonzini , Richard Henderson Cc: gcc-patches@gcc.gnu.org, Vladimir Yakovlev , "Kumar, Venkataramanan" Subject: Re: [PATCH, dataflow]: Fix PR55845, 454.calculix miscompares on x86 AVX due to movement of vzeroupper Message-ID: <20130106162251.GX7269@tucnak.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-01/txt/msg00254.txt.bz2 On Sun, Jan 06, 2013 at 04:48:03PM +0100, Uros Bizjak wrote: > --- df-problems.c (revision 194945) > +++ df-problems.c (working copy) > @@ -3916,6 +3916,10 @@ can_move_insns_across (rtx from, rtx to, rtx acros > break; > if (NONDEBUG_INSN_P (insn)) > { > + /* Do not move unspec_volatile insns. */ > + if (GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE) > + break; > + Shouldn't UNSPEC_VOLATILE be handled similarly in the across_from .. across_to loop? Both UNSPEC_VOLATILE and volatile asm are handled there just with trapping_insns_in_across |= may_trap_p (PATTERN (insn)); but your new change doesn't prevent moving just trapping insns across UNSPEC_VOLATILE, but any insns whatsoever. So supposedly for UNSPEC_VOLATILE the first loop should just return false; (or fail = 1; ?). For asm volatile I guess the code is fine as is, it must always describe what exactly it modifies, so supposedly non-trapping insns can be moved across asm volatile. > if (may_trap_or_fault_p (PATTERN (insn)) > && (trapping_insns_in_across || other_branch_live != NULL)) > break; You could do the check only for may_trap_or_fault_p, all UNSPEC_VOLATILE may trap. BTW, can't UNSPEC_VOLATILE be embedded deeply in the pattern? So volatile_insn_p (insn) && asm_noperands (PATTERN (insn)) == -1? But perhaps you want to treat that way only UNSPEC_VOLATILE directly in the pattern and all other UNSPEC_VOLATILE insns must describe in detail what exactly they are changing? This really needs to be better documented. Jakub