Re: relax jalr $t9 [R_MIPS_JALR symbol] to bal symbol

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 25, 2003, Richard Henderson <rth at redhat dot com> wrote:

> On Tue, Mar 25, 2003 at 01:19:58AM -0300, Alexandre Oliva wrote:
>> If we actually did any size-changing relaxation, we might have offset
>> changes, but since we don't, this is not an issue.

> Right now.  Until someone makes some change somewhere else.

If someone makes a change that changes this kind of assumption, I'm
sure we're going to see a *lot* of code break.  I can't think of a
relaxation pass that isn't based on the assumption that either we grow
code if we find that some relocation will overflow, or shrink it if we
find that a shorter code sequence could be used with relocations that
wouldn't overflow.  One could do both if every such transformation is
reversible, at the risk of entering endless loops, but correctness of
the relaxation pass is based on the assumption that addresses and
offsets it uses to decide whether some relaxation can (not) be
applied, at least on the last round, are final.  Making any changes to
addresses or offsets after the relaxation code has committed to
certain changes will break stuff, so the change you say someone might
make would be an utter mistake.

>> But then, we wouldn't be able to tell for sure
>> whether the jump would be in-range before making the transformation,

> Huh?  Sure we can.  If we couldn't, we wouldn't be able to
> make the transformation at all.

See, you agree with me :-) :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist                Professional serial bug killer