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 On Wed, Apr 30, 2014 at 2:25 AM, Daniel Sanders <Daniel.Sanders at imgtec.com>wrote:> 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. > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Brandon Hill > *Sent:* 29 April 2014 22:35 > *To:* llvmdev at cs.uiuc.edu > *Subject:* [LLVMdev] MIPS n64 ABI and non-PIC > > > > 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 > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140502/2c5ee651/attachment.html>
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).
From: Brandon Hill [mailto:bgh.list.reader at gmail.com]
Sent: 02 May 2014 19:53
To: Daniel Sanders
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] MIPS n64 ABI and non-PIC
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
On Wed, Apr 30, 2014 at 2:25 AM, Daniel Sanders <Daniel.Sanders at
imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote:
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.
From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces
at cs.uiuc.edu>] On Behalf Of Brandon Hill
Sent: 29 April 2014 22:35
To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: [LLVMdev] MIPS n64 ABI and non-PIC
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140502/bba04267/attachment.html>
Daniel Sanders <Daniel.Sanders at 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