From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25715 invoked by alias); 22 Mar 2019 17:44:55 -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 25703 invoked by uid 89); 22 Mar 2019 17:44:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=iff, decl_mode, 22106, relying X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com Received: from mail-oln040092064045.outbound.protection.outlook.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (40.92.64.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Mar 2019 17:44:52 +0000 Received: from DB5EUR01FT039.eop-EUR01.prod.protection.outlook.com (10.152.4.57) by DB5EUR01HT238.eop-EUR01.prod.protection.outlook.com (10.152.5.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.9; Fri, 22 Mar 2019 17:44:50 +0000 Received: from AM6PR07MB4037.eurprd07.prod.outlook.com (10.152.4.52) by DB5EUR01FT039.mail.protection.outlook.com (10.152.5.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.9 via Frontend Transport; Fri, 22 Mar 2019 17:44:50 +0000 Received: from AM6PR07MB4037.eurprd07.prod.outlook.com ([fe80::c4f3:eebe:a72a:9a61]) by AM6PR07MB4037.eurprd07.prod.outlook.com ([fe80::c4f3:eebe:a72a:9a61%4]) with mapi id 15.20.1709.015; Fri, 22 Mar 2019 17:44:50 +0000 From: Bernd Edlinger To: Richard Biener CC: "gcc-patches@gcc.gnu.org" , Richard Earnshaw , Ramana Radhakrishnan , Kyrill Tkachov , Eric Botcazou Subject: Re: [PATCHv2] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544) Date: Fri, 22 Mar 2019 17:47:00 -0000 Message-ID: References: In-Reply-To: x-microsoft-original-message-id: Content-Type: text/plain; charset="Windows-1252" Content-ID: <8ED6DC7C0A79B9408577F3A0B823EED0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-03/txt/msg01131.txt.bz2 On 3/21/19 12:15 PM, Richard Biener wrote: > On Sun, 10 Mar 2019, Bernd Edlinger wrote: > Finally... >=20 > Index: gcc/function.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gcc/function.c (revision 269264) > +++ gcc/function.c (working copy) > @@ -2210,6 +2210,12 @@ use_register_for_decl (const_tree decl) > if (DECL_MODE (decl) =3D=3D BLKmode) > return false; >=20 > + if (STRICT_ALIGNMENT && TREE_CODE (decl) =3D=3D PARM_DECL > + && DECL_INCOMING_RTL (decl) && MEM_P (DECL_INCOMING_RTL (decl)) > + && GET_MODE_ALIGNMENT (DECL_MODE (decl)) > + > MEM_ALIGN (DECL_INCOMING_RTL (decl))) > + return false; > + > /* If -ffloat-store specified, don't put explicit float variables > into registers. */ > /* ??? This should be checked after DECL_ARTIFICIAL, but tree-ssa >=20 > I wonder if it is necessary to look at DECL_INCOMING_RTL here > and why such RTL may not exist? That is, iff DECL_INCOMING_RTL > doesn't exist then shouldn't we return false for safety reasons? >=20 I think that happens a few times already before the INCOMING_RTL is assigned. I thought that might be too pessimistic. > Similarly the very same issue should exist on x86_64 which is > !STRICT_ALIGNMENT, it's just the ABI seems to provide the appropriate > alignment on the caller side. So the STRICT_ALIGNMENT check is > a wrong one. >=20 I may be plain wrong here, but I thought that !STRICT_ALIGNMENT targets just use MEM_ALIGN to select the right instructions. MEM_ALIGN is always 32-bit align on the DImode memory. The x86_64 vector instructions would look at MEM_ALIGN and do the right thing, yes? It seems to be the definition of STRICT_ALIGNMENT targets that all RTL instructions need to have MEM_ALIGN >=3D GET_MODE_ALIGNMENT, so the target does not even have to look at MEM_ALIGN except in the mov_misalign_optab, right? The other hunk, where I admit I did not fully understand the comment, tries only to increase the MEM_ALIGN to 64-bit if the stack slot is 64-bit aligned although the target said it only needs 32-bit alignment. So that it is no longer necessary to copy the incoming value. > Which makes me think that a proper fix is not here, but in > target(hook) code. >=20 > Changing use_register_for_decl sounds odd anyways since if we return true > we for the testcase still end up in memory, no? >=20 It seems to make us use the incoming register _or_ stack slot if this funct= ion returns true here. If it returns false here, a new stack slot is allocated, but only if the original stack slot was not aligned. This works together with the other STRICT_ALIGNMENT check in assign_parm_adjust_stack_rtl. Where also for !STRICT_ALIGNMENT target TYPE_ALIGN and MEM_ALIGN are checked, but this seems to have only an effect if an address is taken, in that case I see use_register_for_decl return false due to TREE_ADDRESSABLE (decl), and whoops, we have an aligned copy of the unaligned stack slot. So I believe that there was already a fix for unaligned stack positions, that relied on the addressability of the parameter, while the target relied on the 8-byte alignment of the DImode access. > The hunk obviously misses a comment since the effect that this > will cause a copy to be emitted isn't obvious (and relying on > this probably fragile). >=20 Yes, also that the copy is done using movmisalign optab is important. Thanks Bernd.