LGTM.

Overall patch LGTM. Thanks for adding this. I have one small question about the llvm-readobj test though. IIUC the python file is used to generate the output files for test/tools/llvm-readobj/reloc-types.test. Do we need to run the python script to get the updated relocs.obj.elf-ppc64 file and update the checks for the added relocations in reloc-types.test?

ping

LGTM other then 1 minor comment.

In D57673#1382845, @MaskRay wrote:

If this is allowed. Is there any restriction on the TLS code sequence? e.g. Is it allowed to omit R_PPC64_GOT_TLSGD16_HA?

Addressed several review comments, and fixed bug where I was erroneously relaxing preepmtible symbols.

Updated /moved a few comments.

ping

rebased

Addressed second round of review comments.

Addressed review comments and cut down the test.

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.