This is the mail archive of the mailing list for the binutils 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: MIPS JAL/JALR to BAL transformation for Linux (o32 ABI)

"Fu, Chao-Ying" <> writes:
> In order to utilize this optimization, we need to
> use -mno-explicit-relocs for GCC to let the assembler emit
> BFD_RELOC_MIPS_JALR for shared libraries (-mshared).

I agree that we should try to use BAL in shared libraries.  However it
seems to me that requiring -mno-explicit-relocs is a high price to pay.
Can't we instead change the calls in shared libraries to also use the
PLT (or the locally binding function directly if possible)?

> +/* 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.


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