This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: reload inheritance error breaks openssl on s390
- From: Richard Sandiford <richard at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 03 Aug 2006 11:13:26 +0100
- Subject: Re: reload inheritance error breaks openssl on s390
- References: <orac6vrcxs.fsf@free.oliva.athome.lsd.ic.unicamp.br> <87wt9tizyr.fsf@talisman.home> <orbqr2npjr.fsf@free.oliva.athome.lsd.ic.unicamp.br>
Alexandre Oliva <aoliva@redhat.com> writes:
> Of course there's force_reg() too, but those are (almost?) always
> short-lived enough that they always get a register, and are often
> trivially rematerialized as opposed to getting a stack slot, so the
> problem never hits. Or so I reasoned.
To be honest, I'm not convinced ;) I know it's stating the obvious,
but reload can only rematerialise invariants, and many of REG_EXPR-less
registers aren't invariant. Relying on the others being "short lived
enough" seems very dodgy. ;) We need to be correct by design.
Many places call force_reg() or call gen_reg_rtx() without attaching a
REG_EXPR. I'm not sure all of them are necessarily short-lived to start
with. E.g. what about registers created by get_hard_reg_initial_val()?
But even those that do start out short-lived -- such as those created
as a temporary by the move expanders -- might have their lifetimes
extended by cse, gcse, etc.
> Hmm... Instead of going through simplifying all mem addresses we
> compare with, I wonder if it would be safe to apply the same machinery
> that breaks up the 4840 offset into 4096 and 744 before searching.
> /me wonders where this happens, and if searching for the original
> elimination address *and* the broken-up addressing mode, if different,
> would cover all cases. If so, this would probably be the way to go.
It's done by LEGITIMIZE_RELOAD_ADDRESS, and unfortunately, I'm almost
certain you can't call that in delete_output_reload.
Richard