[PATCH] D53383: [PowerPC] Make no-PIC default to match GCC - LLVM

Sean Fertile via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 13 13:10:15 PST 2018


sfertile accepted this revision.
sfertile added a comment.
This revision is now accepted and ready to land.

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 <https://github.com/llvm-mirror/llvm/blob/65bbccae60d50bd2a5737ab8749cd0a193f755b1/lib/Target/TargetLoweringObjectFile.cpp#L223> 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.

I think using static relocation model is the right approach here. I don't think we should deviate from the same default xlc and gcc uses without  strong benefit to motivate the difference, and an understanding that the option difference will not impact compatibility.

LGTM


https://reviews.llvm.org/D53383





More information about the llvm-commits mailing list