Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like:
if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) {
}
around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can’t find any discussion of it anywhere. I ran into this when trying to see why --relocation-model=static had no effect on the output. I’m game to test it, but it would help to know that it isn’t pointless due to a significant known issue.
Brandon
GCC does the same thing. I haven’t found anything written down that explains this yet but I believe it’s that PIC consistently generates faster and smaller code than non-PIC for N64.
For example, a non-PIC implementation of getAddrLocal() would probably generate something like this:
lui $1, %highest(foo)
add $1, $1, %higher(foo)
dsll $1, $1, 32
lui $2, %hi(foo)
add $2, $2, %lo(foo)
add $1, $1, $2
which is 6 instructions per-symbol referenced. The current PIC implementation generates this:
lui $1, %hi(%neg(%gp_rel(bar)))
daddu $1, $1, $25
daddiu $1, $1, %lo(%neg(%gp_rel(bar)))
ld $2, %got_disp(foo)($1)
which is a one-time cost of 3 instructions to set up the GOT pointer, plus one load per-symbol referenced.
Actually, GCC will generate non-PIC for n64. Maybe that is a recent addition, but we are using its results. Even if PIC may be faster and smaller code, it seems that non-PIC is still useful for bare-metal. That’s the driver of my interest. I guess we can just test what happens when that part of the conditional is removed. As a side note, if it isn’t supported then we should probably have the compiler warn the user that the two flags aren’t compatible.
Brandon
Ok, I didn’t know that. It looks like gcc’s behaviour is triple-dependent. My mips-mti-linux-gnu-gcc toolchain (last updated in January) always generates PIC code for –fPIC, -fno-PIC, and neither option. I’ve just tried the latest mips-sde-elf-gcc toolchain and found it emits non-PIC code for –fno-PIC and neither option, and errors out with –fPIC (without additional options).
Daniel Sanders <Daniel.Sanders@imgtec.com> writes:
Ok, I didn't know that. It looks like gcc's behaviour is
triple-dependent. My mips-mti-linux-gnu-gcc toolchain (last updated in
January) always generates PIC code for –fPIC, -fno-PIC, and neither
option. I've just tried the latest mips-sde-elf-gcc toolchain and found
it emits non-PIC code for –fno-PIC and neither option, and errors out
with –fPIC (without additional options).
It's really -mabicalls-dependent, with the default -mabicalls depending
on triple like you say. -fPIC -mno-abicalls isn't supported.
Note that even -mabicalls code will use non-PIC code with -msym32.
(The PLT/copy-reloc model requires 32-bit symbols.)
Thanks,
Richard