MIPS: Add comment to explain why PIC code gen is the default for MIPS

[mseaborn]

Summary

The question of why LLVM defaults to PIC for MIPS, when GCC doesn't, keeps coming up.

It seems like it would be useful to add an explanatory comment, even if it's only a partial explanation.

This is based on:

• What Sasa Sankovic wrote in http://reviews.llvm.org/D3928: "MIPS traditionally used PIC relocation model, to be able to use shared libraries. PLT support (which enables non-PIC code to use shared libraries) was added to MIPS only recently, in 2008. I suppose at that time GCC switched to using non-PIC as default. I don't know why LLVM still uses PIC."
• This thread from 2008, "RFC: Adding non-PIC executable support to MIPS": https://sourceware.org/ml/binutils/2008-06/msg00280.html
• Part of http://www.linux-mips.org/wiki/PIC_code, which is presumably out of date (from 2008 or earlier), which says: "All userspace code in Linux is PIC code. It is currently not possible to mix non-PIC object files and PIC object files when linking. Therefore the customer needs to generate PIC objects."

Please feel free to suggest a different wording for the comment!

[sstankovic]

LGTM. I would only add that not only GCC but Clang too has non-PIC as default.

Btw, one area that still requires PIC code is creating .so files. Creating .so files from non-PIC code requires that non-PIC relocations be converted into dynamic ones (that would be later resolved by dynamic linker, based on the memory address where .so file is loaded), and Mips linker (currently) cannot convert most of the non-PIC relocation types into dynamic ones. So .so files must be created with -fPIC on MIPS.

[petarj]

lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.cpp

103

As I mentioned in D5442, PIC code is generally more efficient in N64, so this part of the comment is not completely valid. In those cases, setting RM to Reloc::Static will actually have no effect, since PIC code will be generated.
It is true that the reasons for PIC in MIPS Linux are historical en générale, though in LLVM case this might have been caused by different defaults at the time.

[petarj]

I have modified this in r265949 [1], so this change can be abandoned now.

[1] r265949, http://llvm.org/klaus/llvm/commit/d2c18d6b60e47de333ae6ffeeb1e7eaeb6e6030a/

[seanbruno]

Can someone close this review as it has been committed in a different form?

[mseaborn]

Closing as requested.

lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.cpp

 
 static MCCodeGenInfo *createMipsMCCodeGenInfo(StringRef TT, Reloc::Model RM,
                                               CodeModel::Model CM,
                                               CodeGenOpt::Level OL) {
   MCCodeGenInfo *X = new MCCodeGenInfo();
   if (CM == CodeModel::JITDefault)
     RM = Reloc::Static;
   else if (RM == Reloc::Default)
+    // We currently default to PIC code generation.  This differs from
+    // other architectures, such as x86 and ARM, and from GCC's handling of
+    // MIPS.  The reasons for defaulting to PIC appear to be historical.
+    // It used to be the case that the linker did not support producing
+    // dynamically-linked executables containing non-position-independent
+    // code on MIPS.
+    // TODO: Linker support for non-PIC was added in 2008, so it may be
+    // possible to make non-PIC the default here now, which would have the
+    // benefit of generating slightly faster code.
     RM = Reloc::PIC_;
   X->InitMCCodeGenInfo(RM, CM, OL);
   return X;
 }
 
 static MCInstPrinter *createMipsMCInstPrinter(const Target &T,
                                               unsigned SyntaxVariant,
                                               const MCAsmInfo &MAI,