From patchwork Sun Jan 6 16:43:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 209783 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 2D14B2C0080 for ; Mon, 7 Jan 2013 03:44:17 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1358095458; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Cc:Subject:Date:Message-ID:User-Agent: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=VccY2tR D3i09A2hJ9n8D7nOHE9I=; b=fCoZE0lplZ/3IOH9oAVzv5s9H3AFhC0oZpR3tF/ GVZEA8HRgzFPAzQJtR21yofHZF2rMt6mTrLWXc8Y/YbrVWWl6KHCk7MzmvBYAcSj Tpw3M1xgJ3tFeryYraSJozxWMTXYBkNQG1e3eVp/dH6q+bj6wfxS66YrRfLntZm6 4MM8= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=DDmx8A3T6b/kScXi7gQLWvuVToIs/X1rrQMdTsiniPRxgMkxHtveiJy3WCFe7M skSiy05EHwQViBGo2dBzrDki5bLUmLm/GkBHmtp+PUGalL6YDCMx8+sc4zBPv4CI 9O2XX6Wb5SHPd9nflbV/0CWVqBqqJ20tkNtudginWhldM=; Received: (qmail 12373 invoked by alias); 6 Jan 2013 16:44:11 -0000 Received: (qmail 12365 invoked by uid 22791); 6 Jan 2013 16:44:10 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED, TW_VZ X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 06 Jan 2013 16:44:04 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 89A6D290034; Sun, 6 Jan 2013 17:44:12 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QydIKuUHnvt; Sun, 6 Jan 2013 17:44:12 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 22FA7290001; Sun, 6 Jan 2013 17:44:12 +0100 (CET) From: Eric Botcazou To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Uros Bizjak , Paolo Bonzini , Richard Henderson , Vladimir Yakovlev , "Kumar, Venkataramanan" Subject: Re: [PATCH, dataflow]: Fix PR55845, 454.calculix miscompares on x86 AVX due to movement of vzeroupper Date: Sun, 06 Jan 2013 17:43:02 +0100 Message-ID: <50281741.4qfAGM0b1s@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.16-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: <20130106162251.GX7269@tucnak.redhat.com> References: <20130106162251.GX7269@tucnak.redhat.com> MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org > 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. Yes, I think that we should document that UNSPEC_Vs are full optimization barriers so the existing blockage insn of all ports are really blockage. That's already what is implemented and seems non-controversial (unlike the volatile asms). Something like: /* Vector of addresses, stored as full words. */ I'd also propose that blockage insns always be UNSPEC_Vs (that's already the case in practice, but the manual also lists volatile asms). And I'm somewhat dubious about the distinction between toplevel and embedded UNSPEC_Vs in a pattern; IMO, that shouldn't make any difference. Index: rtl.def =================================================================== --- rtl.def (revision 194946) +++ rtl.def (working copy) @@ -213,7 +213,9 @@ DEF_RTL_EXPR(ASM_OPERANDS, "asm_operands */ DEF_RTL_EXPR(UNSPEC, "unspec", "Ei", RTX_EXTRA) -/* Similar, but a volatile operation and one which may trap. */ +/* Similar, but a volatile operation and one which may trap. Moreover, it's a + full optimization barrier, i.e. no instructions may be moved and no register + (hard or pseudo) or memory equivalences may be used across it. */ DEF_RTL_EXPR(UNSPEC_VOLATILE, "unspec_volatile", "Ei", RTX_EXTRA)