[PATCH] D35168: [mips] Handle the `long-calls` feature flags in the MIPS backend

[Simon Dardis via Phabricator via llvm-commits]

sdardis added a comment.

Ok, I've followed up on intermixing -mabicalls and -mlong-calls, and I
was wrong. It's the GCC manual I believe is somewhat misleading.

In the basic case of -mabicalls & -mlong-calls, they don't work together
as abicalls code is pic and long-calls is static only.

However, the MIPS non-PIC ABI specification[1] also mixing static
and pic code, cpic. In this case, when code is produced with -mno-shared,
calls to locally defined functions do not have to go through the GOT,
and are either 'jal' or a long call sequence. Calls to functions which
are not locally defined use the GOT and jalr as normal.

Until we get proper support for -mshared / -mno-shared, we should only
allow -mlong-calls with -mno-abicalls.

[1] https://gcc.gnu.org/ml/gcc/2008-07/txt00000.txt



================
Comment at: lib/Target/Mips/MipsISelLowering.cpp:3024
 
+  if (Subtarget.useLongCalls() && Subtarget.hasSym32() && !IsPIC) {
+    // Get the address of the callee into a register to prevent
----------------
sdardis wrote:
> atanasyan wrote:
> > sdardis wrote:
> > > Nit:// FIXME: Add support for 64 bit symbols.
> > > Add support for 64 bit symbols
> > How can I force compiler to generate the `jal` instruction to jump to 64-bit symbol? I.e. it looks like with `-mabi=64` the compiler always uses the `jalr` instruction.
> You need to use the static relocation model and turn off abicalls (target feature +noabicalls). The N64 abi defaults to PIC as synthesizing the address of a symbol is quite expensive, so PIC is preferred for that abi.
That check should also test that abicalls are not being used.


Repository:
  rL LLVM

https://reviews.llvm.org/D35168