[llvm-dev] [cfe-dev] -fpic ELF default: reclaim some -fno-semantic-interposition optimization opportunities?

Fāng-ruì Sòng via llvm-dev llvm-dev at lists.llvm.org
Sun Jun 6 10:50:41 PDT 2021

On Sun, Jun 6, 2021 at 7:08 AM Joerg Sonnenberger via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On Sat, Jun 05, 2021 at 06:08:57PM -0700, Fāng-ruì Sòng via llvm-dev wrote:
> > On 2021-06-06, Joerg Sonnenberger wrote:
> > > On Fri, Jun 04, 2021 at 03:26:53PM -0700, Fāng-ruì Sòng via llvm-dev wrote:
> > > > Fixing the last point is actually easy: let -fno-pic use GOT when
> > > > taking the address of an non-definition function.
> > >
> > > I'd far prefer to have an attribute to explicitly say that the address
> > > of a given symbol should always be computed indirectly (e.g. via GOT).
> > > That gives the explicit control necessary for libraries without
> > > penalizing the larger executables like clang.
> > >
> > > Joerg
> >
> > Taking the address (in code) of a non-definition function is rare,
> > rarer after optimization. At least when building clang, I cannot find
> > any penalizing.
> I was not talking about just functions. I can't even think of a case
> where pointer equality for function pointers matters. But the case I
> care far more about is being able to avoid copy relocations for global
> variables and that's the same problem (loading the address of a symbol).
> Joerg

On the Clang side, `-fno-pic -fno-direct-access-external-data` uses
GOT to access a default visibility global variable today.
If all TUs use this option and assembly files do the right thing, copy
relocations can be avoided.

I know some folks prefer eliminating copy relocations for ABI and
security reasons.
I deliberately make the scope narrow to functions because functions
are where we can improve performance.

The x86 ABI maintainer seems to want to do this in a more complex way.
I have commented on

More information about the llvm-dev mailing list