Re: MIPS JAL/JALR to BAL transformation for Linux (o32 ABI)

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Fu, Chao-Ying" <fu@mips.com> writes:
> Adam Nemet wrote:
>> > +/* True if ABFD is for CPUs that are faster if jal/jalr is 
>> converted to bal.
>> > +   This should be safe for all architectures, but for now 
>> we enable it
>> > +   for RM9000, mips32, mips32r2, mips64, and mips64r2.  */
>> > +#define JAL_JALR_TO_BAL_P(abfd) \
>> > +  (   ((elf_elfheader (abfd)->e_flags & EF_MIPS_MACH) == 
>> E_MIPS_MACH_9000) \
>> > +   || ((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) == 
>> E_MIPS_ARCH_32) \
>> > +   || ((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) == 
>> E_MIPS_ARCH_32R2) \
>> > +   || ((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) == 
>> E_MIPS_ARCH_64) \
>> > +   || ((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) == 
>> E_MIPS_ARCH_64R2))
>> 
>> I think this should be a negative predicate.  As you say JALR->BAL
>> should be a profitable transformation on most CPUs.
>
>   Yes.  If everyone is ok, we can just set JAL_JALR_TO_BAL_P(abfd) to 1.
> (And, fix new test failures due to BAL mismatching.)

Sounds good to me FWIW.  Also, I don't think MIPS_JALR_HINT_P should
be predicated on ISA level.  It should be a format-based decision
instead.  The question then is whether we want to unconditionally
enable this for all non-IRIX targets, at the potential risk of
breaking compatibility with other non-GNU & non-IRIX o32 abicalls
linkers, or whether we want to be more conservative.

I'm not sure whether such linkers exist.  And even if they do,
anyone with specific requirements could easily create a new GAS
configuration that had this macro turned off.  So how about:

#ifdef TE_IRIX
#define MIPS_JALR_HINT_P HAVE_NEWABI
#else
/* As a GNU extension, we use R_MIPS_JALR for o32 too.  */
#define MIPS_JALR_HINT_P 1
#endif

Richard