This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR67383][ARM][4.9]Backport of "Allow any register for DImode values in Thumb2"
- From: Renlin Li <renlin dot li at arm dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, vmakarov at redhat dot com, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- Date: Fri, 16 Oct 2015 14:54:07 +0100
- Subject: Re: [PR67383][ARM][4.9]Backport of "Allow any register for DImode values in Thumb2"
- Authentication-results: sourceware.org; auth=none
- References: <561FB1B4 dot 3060103 at arm dot com> <5620D6F3 dot 102 at foss dot arm dot com>
Hi Ramana,
On 16/10/15 11:52, Ramana Radhakrishnan wrote:
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.
True, It's not a fix. It just allows more flexibility for register
allocation.
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 ?
According to the logic, conflict hard register are excluded from spill
candidate. That's why, in this case, r0, r1, r2 cannot be used.
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 ?
Presumably, ARM state should suffer from the same issue. I will have a look.
Regards,
Renlin
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