[llvm] r251322 - ARM/ELF: Better codegen for global variable addresses.

[Hans Wennborg via llvm-commits]

On Thu, Feb 11, 2016 at 4:22 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> 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.

Sorry, I meant to quote the whole change description, of which I
mostly read "Better codegen for global variable addresses", which
sounded like a good thing to mention :-)