- User Since
- Oct 24 2016, 8:15 AM (116 w, 6 d)
Fri, Jan 18
Thu, Jan 17
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.
Thu, Jan 10
Tue, Jan 8
Mon, Jan 7
Thu, Jan 3
Mon, Dec 31
Forgot to update formatting in one of the tests.
Addressed review comments
Thu, Dec 27
Moved the toc relaxation logic into the PPC64 target.
Mon, Dec 24
Dec 20 2018
Dec 18 2018
Dec 5 2018
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.
Dec 4 2018
Addressed further review comments.
Dec 3 2018
Other then my one comment it LGTM.
Nov 30 2018
Nov 29 2018
Nov 26 2018
Nov 23 2018
Nov 22 2018
Addressed initial review comments.
Nov 19 2018
Added full context
Zaara pointed out I am missing the full context, I'll re post the patch with the context fixed shortly.
Nov 16 2018
Nov 14 2018
Nov 13 2018
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.
Nov 8 2018
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.
Nov 7 2018
Oct 30 2018
Oct 29 2018
Thanks for cleaning this up. LGTM.
Oct 25 2018
Oct 24 2018
Addressed further review comments and update the formatting in the added tests.
Oct 23 2018
Addressed initial review comments.
Oct 18 2018
Abandoned in favour of https://reviews.llvm.org/D53408
Abandoned in favor of [[ https://reviews.llvm.org/D53408 | [PPC64] Long branch thunks. ]]
Oct 16 2018
Oct 15 2018
Reverted in https://reviews.llvm.org/rL344526 until we can figure this out.
Oct 11 2018
I've reverted this for now.
This test is failing on the powerpc bots as well as hexagon and s390x:
Oct 4 2018
Removed extra space in comment, and incorrect assert.