This is the mail archive of the gcc-patches@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]

Re: reload inheritance error breaks openssl on s390


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


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