On 11 August 2015 at 12:28, Ramana Radhakrishnan <ramana.radhakrish...@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 >>>