This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, Richard Biener <rguenther at suse dot de>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, Eric Botcazou <ebotcazou at adacore dot com>, Jeff Law <law at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 4 Sep 2019 15:00:45 +0000
- Subject: Re: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BbEg645aVObUgH2I3ahjoWjCg95pg/EIc0OJM9sdAqs=; b=jWyxKBr7xXMuqkMYx/2ap61F9Inz9m7QOAHlwwf9HKRJ3cCA/AwHuTxzG3aWx3dhO3rffdhBdDvKzigimp/GcBzeDu5EiHsq0qAGr40IVhQJmxc4pzCM1a+Y26paeKuFr04Lo6IxkFQ6vFsx+rMWFtAarPI7/5lq/pTifCUUQW1tQrPJfqSe0zOR9IHJbn1vlyK4mGGnL84JFO25Oe2DDz+57kVK3tAMKg1qSoALgz1WGBD6UHCY8gaRTlR4//wuIxooPjgoax5pbhdlLvkh0bkFQq7NpQYbeQFO4OvdvfRoR/w3/fZRmEl7za9Y4iuUew3gdjoe7fQL+xhvWtpFZQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cxi7Asedy8dp1Q0jdaKdZh3DDaPkQC5toNRsjCsSTqG1y5xvETkjbsUnOWvCHrvYi6o3hDYEsRyaMb67OpA0VKg2J5DrmpaozVqlCWicJAMxHhi/hLoYf84IZ19/hYbexusZniElmtmC0v6PyHYpC/vEvrLXUGEAd8fcoK1NAV050PTAfUZqFhf2YYGW9a6MIae1EyN76K9iHvLsBjIsU2z4f5uvLSzsLGLutTj0X1v3Rvm+1kNPIVtH7QFWCtY5pknWhXU5vOV/gVqkS4ZvmUnb+DgXefeWeRFslMEI15YjRUSBsDWLfUacir2E6YSMSRz35MWxNcgxyCaxhxZ0xQ==
- References: <AM6PR07MB4037775DF79E0229DCCA425AE44F0@AM6PR07MB4037.eurprd07.prod.outlook.com> <AM6PR10MB2566A6E51DC500187D9EC6CFE4D90@AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM> <DB8PR10MB2569255E3191B5C7FA70D338E4D70@DB8PR10MB2569.EURPRD10.PROD.OUTLOOK.COM> <alpine.LSU.2.20.1908141319050.11741@zhemvz.fhfr.qr> <AM6PR10MB256602B22A8F0DA91782D76DE4AD0@AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM> <alpine.LSU.2.20.1908151032040.32458@zhemvz.fhfr.qr> <AM6PR10MB2566EF4119F45406B60B3972E4AC0@AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM> <alpine.LSU.2.20.1908151437430.32458@zhemvz.fhfr.qr> <AM6PR10MB2566B60823F40D98F4F2D55DE4AC0@AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM> <A61C6A2B-A22F-475B-A150-5065DB4686CC@suse.de> <AM6PR10MB2566627D2A92173775D78936E4AC0@AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM> <c4e0d051-5b17-2bfa-d0c9-383fa65f8ae2@arm.com> <AM6PR10MB256679EB47FAEB6088C8FD8DE4B80@AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM> <1806cfa6-30c6-0719-0c4d-0fc56accd5e7@arm.com>
On 9/4/19 4:14 PM, Richard Earnshaw (lists) wrote:
> On 04/09/2019 14:28, Bernd Edlinger wrote:
>> On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote:
>>> 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!!!!
>
Yeah, that changed since r275063 introduced the unaligned-load/storedi
r275063 | edlinger | 2019-08-30 12:38:37 +0200 (Fr, 30. Aug 2019) | 10 Zeilen
Geänderte Pfade:
M /trunk/gcc/ChangeLog
M /trunk/gcc/config/arm/arm.c
M /trunk/gcc/config/arm/arm.md
M /trunk/gcc/config/arm/neon.md
2019-08-30 Bernd Edlinger <bernd.edlinger@hotmail.de>
* config/arm/arm.md (unaligned_loaddi,
unaligned_storedi): New unspec insn patterns.
* config/arm/neon.md (unaligned_storev8qi): Likewise.
* config/arm/arm.c (gen_cpymem_ldrd_strd): Use unaligned_loaddi
and unaligned_storedi for 4-byte aligned memory.
(arm_block_set_aligned_vect): Use unaligned_storev8qi for
4-byte aligned memory.
Since other than the movdi they are not split up but stay as ldrd/strd.
But for some unknown reason ira assigns r4-5 to those although also
r1-2 would be available. :-(
Bernd.