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

[Yvan Roux]

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
>