[PATCH] D31528: [ELF][MIPS] Multi-GOT implementation

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 17 16:49:45 PDT 2017


On Tuesday, April 4, 2017, Simon Atanasyan via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Hi,
>
> On Sat, Apr 1, 2017 at 4:20 AM, Rui Ueyama via Phabricator
> <reviews at reviews.llvm.org <javascript:;>> wrote:
> >
> > This is not your fault, but I have to say that this MIPS GOT layout is
> very odd,
> > too different from other architectures, and too complicated. I want to
> avoid supporting
> > this unless I'm convinced that it is absolutely necessary. It seems to
> me that MIPS
> > needs a clean, common new ABI. Only the MIPS ABI imposes a lot of
> restrictions
> > on the size of GOT sections and the order of GOT section members, even
> though MIPS
> > as a processor is an ordinary RISC ISA. This change would really hurt
> maintainability
> > of LLD which I already found some MIPS-specific behavior is hard to keep
> it right
> > when editing code for all the other architectures.
>
> MIPS will not always use old, obsoleted ABIs. It will switch to new
> one. But it does not
> happen this year or so. Besides other obstacles, there is a hardware
> problem prevents from
> fast switching and common acceptance of the new ABI. Historically many
> MIPS instructions
> are partitioned as 16 bit for opcode and 16 bit bit for address/index.
> That is one of
> the source of GOT size limitation and reason of multi-GOT invention.


Limited range for immediates is true for most RISC architectures. Why is
MIPS so special here? What do other arches do?

-- Sean Silva


>
> The biggest part of the patch isolated in the MipsGotSection class. It
> adds some new
> MIPS specific code like new constructor of the DynamicReloc class. But
> at the same
> time it removes some `if (Config->EMachine == EM_MIPS)` statements and
> MIPS specific
> fields from the `SymbolBody` class.
>
> > I wonder what is the performance penalty you would have to pay when you
> use the -mxgot
> > option. With the option, you'll need three instructions as opposed to a
> single instruction
> > to access an GOT entry. Does that actually make observable difference in
> performance?
>
> Regular (without -mxgot) access to GOT requires a single instruction:
>
> lw  t9,0(gp)
>
> I was wrong when say about two instructions. With -mxgot option we get
> three instructions.
>
> lui     at,0x0
> addu    at,at,gp
> lw      t9,0(at)
>
> In case of MIPS global offset table is used not only to call external
> functions / access
> external data but for local calls / access under some conditions. So
> using -mxgot we can
> easily grow the code size and reduce performance.
>
> > ================
> > Comment at: ELF/DriverUtils.cpp:31
> >  using namespace llvm;
> > +using namespace llvm::opt;
> >  using namespace llvm::sys;
> > ----------------
> > Do you need this?
>
> It's necessary to use the `HelpHidden` flag in the `mips_got_size`
> option definition. That allows to hide this option from the list shown
> by the `-help`.
>
> --
> Simon Atanasyan
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org <javascript:;>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170417/55a609bd/attachment.html>


More information about the llvm-commits mailing list