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: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- Cc: Alan Lawrence <alan dot lawrence at arm dot com>, "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: Wed, 12 Aug 2015 15:32:14 +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> <CAD57uCez=Re-uJ1zNj113C+__ONShCFjJQJgfvVMrqHh9jBF4w at mail dot gmail dot com> <55C9CE5B dot 3060201 at foss dot arm dot com>
On 11 August 2015 at 12:28, Ramana Radhakrishnan
<ramana.radhakrishnan@foss.arm.com> wrote:
>>
>> 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() {}
>
> Yep we may well have DImode values in the VFP register bank.
>
>>
>>> 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.
>
>
>
> It sounds to me like checking against LAST_ARM_REGNUM is the better approach. The additional test in the movdi expander was to prevent illegitimate ldrd / strd instructions from being generated.
>
> Thus, OK if there are no regressions - Please give it some time to bake on trunk before backporting to FSF 5 and / or do some additional validation (including the regression testsuite) before doing the backport.
No regressions on trunk for both armeb-linux-gnueabihf and
arm-linux-gnueabihf, thus I've committed it as r226811. I'll validate
the backport to FSF 5 before committing it.
Thanks
Yvan
>
>
> regards
> Ramana
>
>
>>
>> Thanks,
>> Yvan
>>
>>
>> yes
>>
>>
>>> --Alan
>>>