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

[Simon Dardis via Phabricator via llvm-commits]

sdardis added a comment.

> Do you know why gcc does not warn in this case?

GCC's manual says that -mlong-calls has no effect on code that uses -mabicalls. I'm assuming it's a deficiency in the MIPS backend of GCC not to identify this case and report it.

> Moreover gcc -mabicalls -mlong-calls generates jalr not jal instructions. Is it a bug in gcc?

This looks like it's some optimization kicking in to store function addresses only in the GOT in the case of static code that uses abicalls and long-calls. I'll have a further look tomorrow about this.



================
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
----------------
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.


Repository:
  rL LLVM

https://reviews.llvm.org/D35168