[llvm] r251322 - ARM/ELF: Better codegen for global variable addresses.
Peter Collingbourne via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 11 16:22:50 PST 2016
On Thu, Feb 11, 2016 at 04:17:49PM -0800, Hans Wennborg wrote:
> On Mon, Oct 26, 2015 at 11:23 AM, Peter Collingbourne via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > Author: pcc
> > Date: Mon Oct 26 13:23:16 2015
> > New Revision: 251322
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=251322&view=rev
> > Log:
> > ARM/ELF: Better codegen for global variable addresses.
> >
> > In PIC mode we were previously computing global variable addresses (or GOT
> > entry addresses) by adding the PC, the PC-relative GOT displacement and
> > the GOT-relative symbol/GOT entry displacement. Because the latter two
> > displacements are fixed, we ended up performing one more addition than
> > necessary.
> >
> > This change causes us to compute addresses using a single PC-relative
> > displacement, resulting in a shorter code sequence. This reduces code size
> > by about 4% in a recent build of Chromium for Android.
> >
> > As a result of this change we no longer need to compute the GOT base address
> > in the ARM backend, which allows us to remove the Global Base Reg pass and
> > SDAG lowering for the GOT.
> >
> > We also now no longer use the GOT when addressing a symbol which is known
> > to be defined in the same linkage unit. Specifically, the symbol must have
> > either hidden visibility or a strong definition in the current module in
> > order to not use the the GOT.
> >
> > This is a change from the previous behaviour where we would use the GOT to
> > address externally visible symbols defined in the same module. I think the
> > only cases where this could matter are cases involving symbol interposition,
> > but we don't really support that well anyway.
> >
> > Differential Revision: http://reviews.llvm.org/D13650
>
> Might be worth mentioning in the ARM section of the release notes?
On account of the behaviour change in the last paragraph? I had to revert
that aspect of the change in r251342.
Thanks,
--
Peter
More information about the llvm-commits
mailing list