This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/66591] [SH] ICE: in get_reload_reg, at lra-constraints.c:633 with -mlra


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]