From patchwork Mon Jun 11 14:38:03 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Earnshaw X-Patchwork-Id: 164140 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 BEC441007D3 for ; Tue, 12 Jun 2012 00:38:28 +1000 (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=1340030309; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=wqQ+2PTbfLg2nV8H0kZJA/qdx8Q=; b=FFJ9TZ9rP9MCqy7 RKarmRct6UOonlmzaodHAEC4vqyryhs9lwROzPVJaivkZLRz35yrI3bUGAK5vK+q lyC7infaLOTIuvwexO4cudnm07fxk+TaHi5RYmyi1sloyQoUQLvlrI7hVXTPiVQV vbNmy1GGhskMufzwK5f6UQm9PiHw= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-MC-Unique:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ondX+VQarMEejGlKWcvhTuvkxS9DsH1o1nn27vKOAtaQb1VaqXYn4Zd0f14TVx 8EKKLVEB6rGnDcjiTxgeKYGz1LiQxY4NuGsJGHpZ7eyohCyo2AdXmX39kpJXaZqc 0mdub5o0ZLzIhDyojfLO8Ev8uMMfuV0t1Q1xbzxcQfLiU=; Received: (qmail 32337 invoked by alias); 11 Jun 2012 14:38:21 -0000 Received: (qmail 32194 invoked by uid 22791); 11 Jun 2012 14:38:20 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 14:38:06 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 11 Jun 2012 15:38:04 +0100 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jun 2012 15:38:35 +0100 Message-ID: <4FD602CB.2020908@arm.com> Date: Mon, 11 Jun 2012 15:38:03 +0100 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Richard Guenther CC: "gcc-patches@gcc.gnu.org" Subject: Re: [RFC] Target-specific limits on vector alignment References: <4FD5EFC2.5010001@arm.com> In-Reply-To: X-MC-Unique: 112061115380401801 X-IsSubscribed: yes 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 On 11/06/12 15:17, Richard Guenther wrote: > On Mon, Jun 11, 2012 at 3:16 PM, Richard Earnshaw wrote: >> The ARM ABI states that vectors larger than 64 bits in size still have >> 64-bit alignment; never-the-less, the HW supports alignment hints of up >> to 128-bits in some cases and will trap in a vector has an alignment >> that less than the hint. GCC currently hard-codes larger vectors to be >> aligned by the size of the vector, which means that 128-bit vectors are >> marked as being 128-bit aligned. >> >> The ARM ABI unfortunately does not support generating such alignment for >> parameters passed by value and this can lead to traps at run time. It >> seems that the best way to solve this problem is to allow the back-end >> to set an upper limit on the alignment permitted for a vector. >> >> I've implemented this as a separate hook, rather than using the existing >> hooks because there's a strong likelihood of breaking some existing ABIs >> if I did it another way. >> >> There are a couple of tests that will need some re-working before this >> can be committed to deal with the fall-out of making this change; I'll >> prepare those changes if this patch is deemed generally acceptable. > > Hm. Where would you use that target hook? > Doh! It was supposed to be in the patch set... :-( in layout_type(), where the alignment of a vector is forced to the size of the vector. R. --- stor-layout.c (revision 188348) +++ stor-layout.c (local) @@ -2131,9 +2131,11 @@ layout_type (tree type) TYPE_SIZE (type) = int_const_binop (MULT_EXPR, TYPE_SIZE (innertype), bitsize_int (nunits)); - /* Always naturally align vectors. This prevents ABI changes - depending on whether or not native vector modes are supported. */ - TYPE_ALIGN (type) = tree_low_cst (TYPE_SIZE (type), 0); + /* Naturally align vectors, but let the target set an upper + limit. This prevents ABI changes depending on whether or + not native vector modes are supported. */ + TYPE_ALIGN (type) + = targetm.vector_alignment (type, tree_low_cst (TYPE_SIZE (type), 0)); break; }