From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96166 invoked by alias); 4 Sep 2019 14:14: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 96158 invoked by uid 89); 4 Sep 2019 14:14:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=hate, HX-Languages-Length:2422 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Sep 2019 14:14:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5D42B28; Wed, 4 Sep 2019 07:14:51 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.91]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1B3FB3F59C; Wed, 4 Sep 2019 07:14:50 -0700 (PDT) Subject: Re: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544) To: Bernd Edlinger , Richard Biener Cc: "gcc-patches@gcc.gnu.org" , Ramana Radhakrishnan , Kyrill Tkachov , Eric Botcazou , Jeff Law , Jakub Jelinek References: From: "Richard Earnshaw (lists)" Message-ID: <1806cfa6-30c6-0719-0c4d-0fc56accd5e7@arm.com> Date: Wed, 04 Sep 2019 14:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-09/txt/msg00194.txt.bz2 On 04/09/2019 14:28, Bernd Edlinger wrote: > On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote: >> On 15/08/2019 20:47, Bernd Edlinger wrote: >>> On 8/15/19 6:29 PM, Richard Biener wrote: >>>>>> >>>>>> Please split it into the parts for the PR and parts making the >>>>>> asserts not trigger. >>>>>> >>>>> >>>>> Yes, will do. >>>>> >>> >>> Okay, here is the rest of the PR 89544 fix, >>> actually just an optimization, making the larger stack alignment >>> known to the middle-end, and the test cases. >>> >>> >>> Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf. >>> Is it OK for trunk? >>> >>> >>> Thanks >>> Bernd. >>> >> >> Index: gcc/testsuite/gcc.target/arm/unaligned-argument-2.c >> =================================================================== >> --- gcc/testsuite/gcc.target/arm/unaligned-argument-2.c    (Revision 0) >> +++ gcc/testsuite/gcc.target/arm/unaligned-argument-2.c    (Arbeitskopie) >> @@ -0,0 +1,19 @@ >> +/* { dg-do compile } */ >> +/* { dg-require-effective-target arm_arm_ok } */ >> +/* { dg-require-effective-target arm_ldrd_strd_ok } */ >> +/* { dg-options "-marm -mno-unaligned-access -O3" } */ >> + >> +struct s { >> +  int a, b; >> +} __attribute__((aligned(8))); >> + >> +struct s f0; >> + >> +void f(int a, int b, int c, int d, int e, struct s f) >> +{ >> +  f0 = f; >> +} >> + >> +/* { dg-final { scan-assembler-times "ldrd" 0 } } */ >> +/* { dg-final { scan-assembler-times "strd" 0 } } */ >> +/* { dg-final { scan-assembler-times "stm" 1 } } */ >> >> I don't think this test is right.  While we can't use an LDRD to load the argument off the stack, there's nothing wrong with using an STRD to then store the value to f0 (as that is 8-byte aligned).  So the second and third scan-assembler tests are meaningless. >> > > Ah, that is very similar to the unaligned-memcpy-2/3.c, > see https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00157.html > > initially that is a movdi, > then in subreg1 it is split in two movsi > which is then re-assembled as ldm > > > Not sure if that is intended in that way. > > Yeah, these are causing me some problems too, but that's because with some changes I'm working on I now see the compiler using r4 and r5, which leads to prologue and epilogue stores that distort the results. Tests like this are generally fragile - I hate 'em!!!! R. > Bernd. >