ld: Why does ppc64 have --no-toc-optimize instead of reusing --no-relax?

[Alan Modra]

On Wed, Aug 05, 2020 at 10:38:22PM -0700, Fangrui Song wrote:
> On 2020-06-08, Alan Modra wrote:
> > On Sun, Jun 07, 2020 at 09:52:31PM -0700, Fangrui Song wrote:
> > > On Sun, Jun 7, 2020 at 6:47 PM Alan Modra <amodra@gmail.com> wrote:
> > > >
> > > > On Sun, Jun 07, 2020 at 05:55:30PM -0700, Fangrui Song wrote:
> > > > > Other backends (e.g. x86, msp430, and riscv) use --no-relax to disable
> > > > > linker relaxations.
> > > >
> > > > Because the ppc64 linker has multiple options to turn off various
> > > > aspects of linker optimisation individually.  Why are you even asking
> > > > a question like this with such an obvious answer?
> > > 
> > > x86-64 recognizes --no-relax and disables GOTPCRELX relaxation. Given
> > > the similarity with toc-indirect to toc-relative relaxation
> > > and the documentation:
> > > 
> > >       --no-relax
> > >            An option with machine dependent effects.  This option is
> > > only supported on a few targets.
> > > 
> > >            On some platforms the --relax option performs
> > > target-specific, global optimizations that become possible when the
> > > linker resolves
> > >            addressing in the program, such as relaxing address modes,
> > > synthesizing new instructions, selecting shorter version of current
> > >            instructions, and combining constant values.
> > > 
> > > I expected that --no-relax included the functionality of
> > > --no-toc-optimize, but it turns out that --no-relax does not mean
> > > anything on ppc64 (no reference of
> > > disable_target_specific_optimizations).
> > 
> > And ppc64 ld.bfd recognises --traditional-format as a way to turn off
> > a whole lot of optimisations.  But your original question was "why did
> > ppc64 have -no-toc-optimize instead of reusing --no-relax", not this
> > new question of why --no-relax doesn't do anything on ppc64.
> > 
> > The simple answer to that is that --relax does nothing on ppc64.  Even
> > x86 does not have what used to be understood as a relaxation pass,
> > where code was edited *and repacked*.  See for example elf-m10200.c
> > mn10200_elf_relax_delete_bytes.
> 
> Does the R_PPC64_PCREL_OPT optimization (something similar to
> R_X86_64_[REX_]GOTPCRELX and --toc-optimize) have a dedicated
> disable/enable option?         Does --no-relax apply:) ?

No, there isn't a way of turning off the PCREL_OPT editing at the
moment.  --traditional-format should probably turn it off.

-- 
Alan Modra
Australia Development Lab, IBM