Re: [PATCH] PR target/67127: [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf

[Yvan Roux <yvan.roux@linaro.org>]

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
>>>