From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1120 invoked by alias); 7 May 2015 11:30:42 -0000 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 Received: (qmail 1097 invoked by uid 89); 7 May 2015 11:30:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 07 May 2015 11:30:39 +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 (Postfix) with ESMTPS id 45385B813C; Thu, 7 May 2015 11:30:37 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47BUZSm002709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 May 2015 07:30:36 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t47BUXdh027154; Thu, 7 May 2015 13:30:33 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t47BUUcv027153; Thu, 7 May 2015 13:30:30 +0200 Date: Thu, 07 May 2015 11:30:00 -0000 From: Jakub Jelinek To: Alan Lawrence Cc: Richard Biener , Richard Earnshaw , "gcc-patches@gcc.gnu.org" , Martin Jambor Subject: Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956) Message-ID: <20150507113030.GH1751@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5548BC73.8030506@foss.arm.com> <20150505125431.GJ1751@tucnak.redhat.com> <5548BF5B.9000904@foss.arm.com> <20150505130650.GK1751@tucnak.redhat.com> <5548C3AB.4050607@foss.arm.com> <20150505142909.GP1751@tucnak.redhat.com> <5548D4A8.4070105@foss.arm.com> <5548D4D6.508@foss.arm.com> <0B1BAF2B-4854-45B2-BD35-C8181CBC4936@suse.de> <554B4990.8030608@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554B4990.8030608@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00539.txt.bz2 On Thu, May 07, 2015 at 12:16:32PM +0100, Alan Lawrence wrote: > So for my two cents, or perhaps three: > > (1) It'd be great to have something in the documentation for > TARGET_FUNCTION_ARG that explains what the contract for the type information > provided is. Even/especially if some of this is "considered useless" i.e. > provided on a best effort basis by compiler analysis. (What happens in other > cases where there are subtyping-like relationships? E.g. genuine C++ > subtyping, or other attributes like const, volatile? I don't imagine that > any backend's ABI depends on those attributes, but do we want to rule that > out, e.g. for attributes that don't exist yet?) Sure, documentation improvements are always welcome. Yes, const/volatile/__restrict, or various attributes like deprecated and various others shouldn't be taken into account when deciding on argument (or return value) passing. > (2) If all backends were expected to save the function prototype in > TARGET_INIT_CUMULATIVE_ARGS and use that, it'd be a shame to duplicate that. > However, it seems this is because other backends don't depend on TYPE_ALIGN. > It doesn't seem unreasonable for argument passing rules to depend on > alignment, however. Most of them don't need that. The type they see in the callee is compatible with the type they see in the caller (except for when the user is supposed to ensure that, like K&R calls or va_arg), otherwise supposedly the FEs should loudly complain. But, stuff like alignment or various other attributes on scalar types are considered useless for function calls by the FEs, and so the backends should treat them IMNSHO too. Thus argument passing rules depending on alignment of scalars is unreasonable. BTW, I've checked llvm and it ignores the alignment attribute on scalar types for argument passing, so the patch I've posted, in addition to allowing GCC to be compatible with itself, would make it compatible with clang too in that regard. > (3) C++11 rules out using __align_as on function arguments, including via a > typedef. GCC allows __attribute__ aligned on arguments *only via a typedef*. > Is that how we want it? Trying to change a GCC extension accepted for many years is not a good idea. Jakub