From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28167 invoked by alias); 19 Mar 2019 13:27:20 -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 27900 invoked by uid 89); 19 Mar 2019 13:27:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_MANYTO,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=HTo:U*ebotcazou, H*Ad:U*ebotcazou, Bernd, bernd X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092067073.outbound.protection.outlook.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (40.92.67.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Mar 2019 13:27:18 +0000 Received: from AM5EUR02FT054.eop-EUR02.prod.protection.outlook.com (10.152.8.55) by AM5EUR02HT083.eop-EUR02.prod.protection.outlook.com (10.152.9.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.9; Tue, 19 Mar 2019 13:27:15 +0000 Received: from AM6PR07MB4037.eurprd07.prod.outlook.com (10.152.8.51) by AM5EUR02FT054.mail.protection.outlook.com (10.152.8.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.9 via Frontend Transport; Tue, 19 Mar 2019 13:27:15 +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; Tue, 19 Mar 2019 13:27:15 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" , Richard Biener , Richard Earnshaw , "Ramana Radhakrishnan" , Kyrill Tkachov , Eric Botcazou Subject: [PING] [PATCHv2] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544) Date: Tue, 19 Mar 2019 14:01:00 -0000 Message-ID: References: In-Reply-To: x-microsoft-original-message-id: <636bdca7-17fe-6140-cc26-2640d975622a@hotmail.de> Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-03/txt/msg00915.txt.bz2 Hi, I'd like to ping for this patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00438.html Thanks Bernd. On 3/10/19 10:42 AM, Bernd Edlinger wrote: > Hi, >=20 > This patch is an update to the previous patch, which takes into account t= hat > the middle-end is not supposed to use the unaligned DI value directly whi= ch > was passed in an unaligned stack slot due to the AAPCS parameter passing = rules. >=20 > The patch works by changing use_register_for_decl to return false if the > incoming RTL is not sufficiently aligned on a STRICT_ALIGNMENT target, > as if the address of the parameter was taken (which is TREE_ADDRESSABLE). > So not taking the address of the parameter is a necessary condition > for the wrong-code in PR 89544. >=20 > It works together with this check in assign_parm_adjust_stack_rtl: > /* If we can't trust the parm stack slot to be aligned enough for its > ultimate type, don't use that slot after entry. We'll make another > stack slot, if we need one. */ > if (stack_parm > && ((STRICT_ALIGNMENT > && GET_MODE_ALIGNMENT (data->nominal_mode) > MEM_ALIGN (stack_= parm)) > ... > stack_param =3D NULL >=20 > This makes assign_parms use assign_parm_setup_stack instead of > assign_parm_setup_reg, and the latter does assign a suitably aligned > stack slot, because stack_param =3D=3D NULL by now, and uses emit_block_m= ove > which avoids the issue with the back-end. >=20 > Additionally, to prevent unnecessary performance regressions, > assign_parm_find_stack_rtl is enhanced to make use of a possible larger > alignment if the parameter was passed in an aligned stack slot without > the ABI requiring it. >=20 >=20 > Bootstrapped and reg-tested with all languages on arm-linux-gnueabihf. > Is it OK for trunk? >=20 >=20 > Thanks > Bernd. >=20