This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/66591] [SH] ICE: in get_reload_reg, at lra-constraints.c:633 with -mlra
- From: "olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 12 Jun 2016 13:55:51 +0000
- Subject: [Bug target/66591] [SH] ICE: in get_reload_reg, at lra-constraints.c:633 with -mlra
- Auto-submitted: auto-generated
- References: <bug-66591-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I have started working on the R0 issue...
An R0-pre-allocating pass might potentially break down again when reload/LRA
tries to emit mem access insns, which have an R0 constraint. Although the
pre-allocating would probably relax the issue, it will be not be bullet proof.
What I'm trying now is to mark R0 as a hardreg and exclude it from the normal
register allocation process. This doesn't mean that it will not be used at
all. E.g. the return values still work OK with that. To avoid many changes in
the code I'm making the 'z' register constraint conditional. Initially it's
disabled and allows all GP regs (i.e. it's like 'r' constraint). Then, after
regular RA,reload/LRA the 'z' constraint is enabled and a special SH pass is
ran to fix up missed 'z' constraints.
Of course this will have some expected regressions because effectively it has
one register less during normal RA. However, I believe the post-alloc strategy
will be more robust than pre-alloc, as it will also deal with stack-frame
access insns generated by reload/LRA. To compensate the regressions, an
additional R0 pre-alloc pass can be done later on.