This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/67127: [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf
- From: Yvan Roux <yvan dot roux at linaro dot org>
- To: Alan Lawrence <alan dot lawrence at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Kyrylo Tkachov <Kyrylo dot Tkachov at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Mon, 10 Aug 2015 19:42:55 +0200
- Subject: Re: [PATCH] PR target/67127: [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf
- Authentication-results: sourceware.org; auth=none
- References: <CAD57uCcQ0ZAxzgyOKOu28GoURGULe3HTKkWj1L_Go-kiY7JsKg at mail dot gmail dot com> <55C8CAF8 dot 30506 at arm dot com>
Hi Alan,
On 10 August 2015 at 18:02, Alan Lawrence <alan.lawrence@arm.com> wrote:
> Yvan Roux wrote:
>>
>> Hi,
>>
>> this patch is a fix for pr27127. It avoids splitting the DI registers
>> into SI ones if it is not allowed, which breaks the introduced loop.
>> I haven't added a testcase as the bug is already exhibited by several
>> regressions (like g++.dg/ext/attribute-test-2.C or g++.dg/eh/simd-1.C)
>> but I can add one if you think it is needed. Cross built and
>> regtested on trunk and gcc-5 branch and the regression mentioned in
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00216.html is not
>> observed.
>>
>> Is it ok for trunk and branch ?
>>
>> Thanks,
>> Yvan
>>
>> gcc/
>>
>> PR target/67127
>> * config/arm/arm.md (movdi): Avoid forbidden modes changed.
>
>
> I've just looked into the above 2 testcases on armeb-none-eabi, and in both
> cases the infinite loop is due to an ldrd/strd with base register 16. So not
> an odd-numbered physical register, but rather something that isn't a
> physical register at all.
Yes in big-endian DI mode value are stored into VFP registers, and
here register 16 is the first of them s0. Just in case you want to do
more test, the issue can be seen with a oneline testcase:
__attribute__((__vector_size__(2 * sizeof(int)))) int fn1() {}
> I observe that FIRST_VIRTUAL_REGISTER is 104, whereas LAST_ARM_REG is 15. So
> it might be that the pattern should check against the latter instead of the
> former - as arm_hard_regno_mode_ok does...
yes, when checking that that the operand register number is lower or
equals to LAST_ARM_REGNUM the infinite loop is avoided. I haven't
pass a full validation so far, but it has the same effect than
checking that the changing mode is authorized. If you think that this
checking makes more sense, I can rerun a full valid.
Thanks,
Yvan
yes
> --Alan
>