On Thu, Oct 15, 2015 at 03:01:24PM +0100, Renlin Li wrote: > Hi all, > > This is a backport patch to loosen restrictions on core registers > for DImode values in Thumb2. > > It fixes PR67383. In this particular case, reload tries to spill a > hard register, and use next register together as a pair to reload a > DImode pseudo register. However, the spilled register number is > odd.This is rejected by arm_hard_regno_mode_ok(). There is no other > register available, so the compiler throws an ICE.
I was not convinced enough by the reasoning provided in the description because this patch was intended to be a bit of an optimization rather than a correctness fix. The command line implies we remove r7 (frame pointer in Thumb2 - historical accident, fno-omit-frame-pointer), r9 (ffixed-r9), r10 (-mpic-register) which leaves us with: * r0, r1 * r2, r3 * r4, r5 as the only free registers available for DImode values for the whole compilation. We then have r0, r1 and r2 live across the insn which means that there are no free registers to handle DImode values under the constraints provided unless LRA / reload can spill the argument registers which it doesn't seem to be able to do in this particular testcase. Vlad, is that correct ? Then I wondered why the same problem did not occur in ARM state given that has the same restriction. In ARM state life is a bit better because the Frame pointer is r11 which means you pretty much have r6 and r7 as well available in addition to the above list, which means that theoretically you can get away with this in ARM state. Can you do some more comparison with ARM state as to why we don't have the same issue there ? > > The test case in PR67383 is too big, so I didn't include it as part > of the patch. I've put up a reduced testcase on the bz, the one I was using to debug. > arm-none-eabi regression test Okay without any new issues. Okay to > backport to 4.9? For changes of this nature please bootstrap and regression test this in arm and thumb2 state as well please. regards Ramana
