From patchwork Fri Jan 17 14:15:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 312078 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 264132C007E for ; Sat, 18 Jan 2014 01:15:36 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=shcL30FsIo0k6j+LY GgMMAL8z5e/LLFSNACQ4p4SMJ3C1o3LLa8T0BjjIay4y6660FfQHNd/phaNsIqN6 Qf0nV0OZrdf7HDSzm9DNkPWLsQiCl1pHOOcV0lDcMaBt2tj4magJxEW0T/RjTTgo IIvRrPxWcakIrEKcBmJ4o+2nh8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=D1tDl0If/EAiVUQs+JEBk6h +1Cc=; b=xEjDWloRU5r8J0GBaa8GJ91RHbfmDICOBXoQdbeoAuXMdej9+4MTgax SaqtPSxNtiduBUi2l9eZp/MJyudkCGC0ZaQNNR1xZ0zLJKBJa8ToKpzwie4qjf8z dGLC4wUDOwTO8P2CJnm49OXlrYdqla+OocwHVO75QTFTcGOKpyIw= Received: (qmail 18430 invoked by alias); 17 Jan 2014 14:15:30 -0000 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 Received: (qmail 18412 invoked by uid 89); 17 Jan 2014 14:15:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jan 2014 14:15:29 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0HEFPZH016065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jan 2014 09:15:25 -0500 Received: from tucnak.zalov.cz (vpn1-7-114.ams2.redhat.com [10.36.7.114]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0HEFLVt001203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jan 2014 09:15:23 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id s0HEFKKa028861; Fri, 17 Jan 2014 15:15:20 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id s0HEFKZL028860; Fri, 17 Jan 2014 15:15:20 +0100 Date: Fri, 17 Jan 2014 15:15:20 +0100 From: Jakub Jelinek To: Uros Bizjak Cc: Eric Botcazou , Kirill Yukhin , "gcc-patches@gcc.gnu.org" , Richard Henderson Subject: Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks. Message-ID: <20140117141520.GG892@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140103115939.GF892@tucnak.redhat.com> <20140103134326.GH892@tucnak.redhat.com> <20140114170932.GR892@tucnak.redhat.com> <20140114191241.GS892@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140114191241.GS892@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On Tue, Jan 14, 2014 at 08:12:41PM +0100, Jakub Jelinek wrote: > For 4.9, if what you've added is what you want to do for performance > reasons, then I'd do something like: Ok, here it is in a form of patch, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2014-01-17 Jakub Jelinek * config/i386/i386.c (ix86_data_alignment): For compatibility with (incorrect) GCC 4.8 and earlier alignment assumptions ensure we align decls to at least the GCC 4.8 used alignments. Jakub --- gcc/config/i386/i386.c.jj 2014-01-16 20:22:50.000000000 +0100 +++ gcc/config/i386/i386.c 2014-01-17 11:56:51.183501322 +0100 @@ -26433,6 +26433,15 @@ ix86_constant_alignment (tree exp, int a int ix86_data_alignment (tree type, int align, bool opt) { + /* GCC 4.8 and earlier used to incorrectly assume this alignment even + for symbols from other compilation units or symbols that don't need + to bind locally. In order to preserve some ABI compatibility with + those compilers, ensure we don't decrease alignment from what we + used to assume. */ + + int max_align_compat + = optimize_size ? BITS_PER_WORD : MIN (256, MAX_OFILE_ALIGNMENT); + /* A data structure, equal or greater than the size of a cache line (64 bytes in the Pentium 4 and other recent Intel processors, including processors based on Intel Core microarchitecture) should be aligned @@ -26447,11 +26456,17 @@ ix86_data_alignment (tree type, int alig if (opt && AGGREGATE_TYPE_P (type) && TYPE_SIZE (type) - && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST - && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= (unsigned) max_align - || TREE_INT_CST_HIGH (TYPE_SIZE (type))) - && align < max_align) - align = max_align; + && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST) + { + if ((TREE_INT_CST_LOW (TYPE_SIZE (type)) >= (unsigned) max_align_compat + || TREE_INT_CST_HIGH (TYPE_SIZE (type))) + && align < max_align_compat) + align = max_align_compat; + if ((TREE_INT_CST_LOW (TYPE_SIZE (type)) >= (unsigned) max_align + || TREE_INT_CST_HIGH (TYPE_SIZE (type))) + && align < max_align) + align = max_align; + } /* x86-64 ABI requires arrays greater than 16 bytes to be aligned to 16byte boundary. */