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

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

cgd at broadcom dot com wrote:
> At Tue, 25 Mar 2003 03:58:53 +0000 (UTC), "Richard Henderson" wrote:
> > > > Secondly, as a follow-up patch I think that !link_info->shared
> > > > should make use of the j/jal absolute forms.
> > > 
> > > You mean, if the branch is out of range, or even if it would be in range?

It is probably simpler to use always j/jal.

> > Um, I dunno.  I suspect that bal will never be slower than jal
> > on any implementation; it's not impossible that the reverse is
> > not true.  Anyone know how this affects Real Life Implementations?
> 
> I'm not aware of any implementations in which jal is slower than bal,
> but my experience isn't that comprehensive, really.
> 
> Due to the way they're done on MIPS, in fact, i believe the
> destination of the bal is "harder" to calculate than the destination
> address of the jump...  (bal requires addition, whereas jal takes the
> upper N bits of the delay slot insn PC and ORs in the index in the
> jump instruction.)

FWIW, I'm not aware of any implemention with different execution times.

> This brings to mind a random question:
> 
> Is there something in the dynamic loader that makes sure that the
> "index in segment" aspect of mips jumps will be handled sanely?
> 
> I can imagine some ... fairly pathological cases (w/ n64) in which a
> given shared object is mapped crossing a 256MB boundary, screwing up
> jumps entirely...  8-)

The n64 ABI draft forbids such a mapping (for DSO's and executables),
AFAICS in order to avoid this problem.

But IIRC gcc has a -long-calls option, the relaxation shouldn't be
done in this case.


Thiemo