[LLVMdev] MIPS n64 ABI and non-PIC

[Brandon Hill]

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>