Fixed look up to handle .toc sections that don't have a relocation for every entry and added a comprehensive test to verify we perform the correct optimization on all access types in this case.

Forgot to update formatting in one of the tests.

Addressed review comments

Moved the toc relaxation logic into the PPC64 target.

In D55498#1339415, @martell wrote:

This was already implemented in rL349511 and rL349772.
Thanks @sfertile and sorry for the noise.
I don't know if there are any notes here that are useful. --got-optimize ?

Committed: https://reviews.llvm.org/rLLD349511

In D54859#1327298, @MaskRay wrote:

Reminder for committing :)

Related to @grimar comment, I am also playing around with doing some of the checking early and mapping toc based relocations that are not-relaxable to got based relocations during scanRelocs. Ideally I'd like to be able to add a separate step for PPC64 once all relocations have been scanned that will iterate over the .toc sections to handle large-code model where any symbols that can't be safely relaxed get added to the .got and all remaining toc based relocations get relaxed. This should hopefully allow me to get rid of the .toc sections in the final binaries, but I'm not familiar enough with large-code model, or gcc and xlc codegen to know if this is feasible yet.

Addressed further review comments.

Other then my one comment it LGTM.

LGTM!

Addressed initial review comments.

Added full context

Zaara pointed out I am missing the full context, I'll re post the patch with the context fixed shortly.

LGTM

I definitely agree we need to fix the PIC by default behavior, PIC implies we need to produce code suitable for a shared object and that has a number of unneeded limitations. I tried to figure out what we are doing differently between pie and static relocation models but don't see much difference.
For the most part we happen to do the same thing, for example the default isOffsetFoldingLegal depends on position-dependence but the PPCTargetLowering overrides it to always return false, we always produce relative jump-tables for ppc64 regardless of the relocation mode, we always use TOC-pointer relative addressing for module local symbols regardles of relocation model . The one difference I did find is TargetLoweringObjectFile::getKindForGlobal although that line looks wrong to me. Static binaries can still link against shared objects. Globals/functions defined in those will not have their addresses resolved at link time, unless maybe this is only a problem on ppc since we don't use copy relocs? (I believe the original PIC by default change was motivated by this but without a clear example I'm not sure why ...). I don't like using the fact there is (or was) bad codegen for the static relocation model as reasoning for picking pie as the default, that bad codegen comes back if the user adds -fno-pie as an option.

Added separate index for use in the branch_lt section and added comment on how we will end up with an empty branch_lt section due removing empty synthetic sections before thunk allocation.

LGTM

In D53652#1279965, @MaskRay wrote:

Hi... can you commit

Thanks for cleaning this up. LGTM.

Addressed further review comments and update the formatting in the added tests.

Addressed initial review comments.

Abandoned in favour of https://reviews.llvm.org/D53408

Abandoned in favor of [[ https://reviews.llvm.org/D53408 | [PPC64] Long branch thunks. ]]

Reverted in https://reviews.llvm.org/rL344526 until we can figure this out.

I've reverted this for now.

This test is failing on the powerpc bots as well as hexagon and s390x:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/20815
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/20534

In D49795#1254181, @ruiu wrote:

This patch seems a bit too intrusive to me, but I'm not sure if it is unavoidable (and thus this is a straightforward implementation) or there's another way to implement it.

Removed extra space in comment, and incorrect assert.