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


On Jul 31, 2006, Richard Sandiford <richard@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> After pondering on a solution for a bit, I realized the MEM_EXPRs
>> would be carried over from the REG_EXPRs in the original pseudo, so we
>> might as well just compare them to tell whether we're addressing the
>> slot for the same pseudo.  I hope this is safe enough.  Failing that,
>> we might have to fold the rtx, special-case this particular situation,
>> or perhaps PLUS handling or somesuch.

> What about pseudos that are not associated with a source-level
> value (and thus have no REG_EXPR)?

Err...  Even if it isn't source-level, you still get a REG_EXPR, for
any SSA-introduced temporary et al, methinks.

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.

> Couldn't the same problem affect those pseudos too?

As argued above (admittedly with lots of hand waving :-), I don't
think so.  But I guess I wouldn't bet my life on it.  I'd love to get
contrary evidence, as unfortunate as it would be to have to find some
more expensive mechanism to do the same...

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.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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