From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23041 invoked by alias); 31 Mar 2015 13:11:24 -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 23030 invoked by uid 89); 31 Mar 2015 13:11:22 -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_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Mar 2015 13:11:21 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-22.uk.mimecast.lan; Tue, 31 Mar 2015 14:11:18 +0100 Received: from [10.2.207.65] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2015 14:11:18 +0100 Message-ID: <551A9CF5.4050202@arm.com> Date: Tue, 31 Mar 2015 13:11:00 -0000 From: Alan Lawrence User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: Jakub Jelinek CC: Richard Biener , Richard Earnshaw , Richard Biener , "gcc-patches@gcc.gnu.org" , Marcus Shawcroft Subject: Re: New regression on ARM Linux References: <55197DAE.1050004@arm.com> <16A8C5AA-994C-4FA3-BC25-8547166DC13C@suse.de> <551A6C46.7010305@foss.arm.com> <551A729F.3090200@foss.arm.com> <551A7B49.7070108@arm.com> <20150331110750.GE2121@tucnak.redhat.com> In-Reply-To: <20150331110750.GE2121@tucnak.redhat.com> X-MC-Unique: chWeRb0wRzGTYeB7q9FWAw-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01658.txt.bz2 Jakub Jelinek wrote: > On Tue, Mar 31, 2015 at 11:47:37AM +0100, Alan Lawrence wrote: >> Richard Biener wrote: >>> But I find it odd that on ARM passing *((aligned_int *)p) as >>> vararg (only as varargs?) changes calling conventions independent >>> of the functions type signature. >> Does it? Do you have a testcase, and compilation flags, that'll make this >> show up in an RTL dump? I've tried numerous cases, including AFAICT your= s, >> and I always get the value being passed in the expected ("unaligned") >> register? >=20 > If the integral type alignment right now matters, I'd try something like: >=20 > typedef int V __attribute__((aligned (8))); > V x; >=20 > int foo (int x, ...) > { > int z; > __builtin_va_list va; > __builtin_va_start (va, x); > switch (x) > { > case 1: > case 3: > case 6: > z =3D __builtin_va_arg (va, int); > break; > default: > z =3D __builtin_va_arg (va, V); > break; > } > __builtin_va_end (va); > return z; > } >=20 > int > bar (void) > { > V v =3D 3; > int w =3D 3; > foo (1, (int) v); > foo (2, (V) w); > v =3D 3; > w =3D (int) v; > foo (3, w); > foo (4, (V) w); > v =3D (V) w; > foo (5, v); > foo (6, (int) v); > foo (7, x); > return 0; > } >=20 > (of course, most likely with passing a different value each time and > verification of the result). > As the compiler treats all those casts there as useless, I'd expect > that the types of the passed argument would be pretty much random. > And, note that even on x86_64, the __builtin_va_arg with V expands into > # addr.1_3 =3D PHI > z_35 =3D MEM[(V * {ref-all})addr.1_3]; > using exactly the same address for int as well as V va_arg - if you incre= ase > the overalignment arbitrarily, it will surely be a wrong IL because nobody > really guarantees anything about the overalignment. >=20 > So, I think the tree-sra.c patch is a good idea - try to keep using the m= ain > type variants as the types in the IL where possible except for the MEM_REF > first argument (i.e. even the lhs of the load should IMHO not be > overaligned). >=20 > As Eric Botcazou said, GCC right now isn't really prepared for under or > overaligned scalars, only when they are in structs (or for middle-end in > *MEM_REFs). >=20 > Jakub >=20 On ARM, I get the arguments being passed in r0 & r1 for every call in bar()= =20 above. It sounds as if this is because the casts are being removed as usele= ss;=20 so the only way for overalignment info to be present, is when SRA puts it t= here. The only way I can get a register to be skipped, is by providing a prototyp= e=20 with alignment specified via a typedef: typedef int aligned_int __attribute__((aligned((8)))); int foo(int a, aligned_int b) {...} //compiles ok whereas specifying alignment directly, is rejected: nonvar.c:2:20: error: alignment may not be specified for 'b' int foo(int a, int b __attribute__((aligned((8))))) ^ Note this is using the GNU __attribute__((aligned)) extension. Trying to us= e C11=20 _Alignas results in a frontend error either way; IIUC the C11 spec deems th= at=20 sort of thing illegal. (1) If we wish to keep the AAPCS principle that varargs are passed just as = named=20 args, we should use TYPE_MAIN_VARIANT inside arm_needs_doubleword_alignment= ,=20 which will then ignore overalignment on both varargs _and named args_. Howe= ver=20 this would be silently ABI-changing....? (2) It seems to me that SRA is the only way for overalignment info to be pr= esent=20 on a value, so the patch to tree-sra.c/create_access_replacement seems to m= ake=20 things more consistent? (3) Given C11 forbids overaligned arguments/parameters, do we wish GNU=20 __attribute__((aligned)) to allow this (via typedefs but not attributes on = the=20 parameters themselves) ? --Alan