<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 4, 2017 at 5:46 AM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span><br>
On Sat, Apr 1, 2017 at 4:20 AM, Rui Ueyama via Phabricator<br>
<<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br>
><br>
> This is not your fault, but I have to say that this MIPS GOT layout is very odd,<br>
> too different from other architectures, and too complicated. I want to avoid supporting<br>
> this unless I'm convinced that it is absolutely necessary. It seems to me that MIPS<br>
> needs a clean, common new ABI. Only the MIPS ABI imposes a lot of restrictions<br>
> on the size of GOT sections and the order of GOT section members, even though MIPS<br>
> as a processor is an ordinary RISC ISA. This change would really hurt maintainability<br>
> of LLD which I already found some MIPS-specific behavior is hard to keep it right<br>
> when editing code for all the other architectures.<br>
<br>
</span>MIPS will not always use old, obsoleted ABIs. It will switch to new<br>
one. But it does not<br>
happen this year or so. Besides other obstacles, there is a hardware<br>
problem prevents from<br>
fast switching and common acceptance of the new ABI. Historically many<br>
MIPS instructions<br>
are partitioned as 16 bit for opcode and 16 bit bit for address/index.<br>
That is one of<br>
the source of GOT size limitation and reason of multi-GOT invention.<br>
<br>
The biggest part of the patch isolated in the MipsGotSection class. It<br>
adds some new<br>
MIPS specific code like new constructor of the DynamicReloc class. But<br>
at the same<br>
time it removes some `if (Config->EMachine == EM_MIPS)` statements and<br>
<span>MIPS specific<br>
fields from the `SymbolBody` class.<br></span></blockquote><div><br></div><div>It is isolated as a separate class, but we still need to understand and modify it when we need to do something for relocation processing. I'm actually trying to change the design of relocation processing, to increase parallelism of relocation processing. We can't parallelize it entirely, but some part (such as making a decision whether a symbol needs a GOT slot or not) can be processed per-file or per-relocation basis.</div><div><br></div><div>Then I found that this part of code is very complex and has grown organically. I tried to reduce its complexity and found that keeping everything right for MIPS is hard. I'm really don't want to increase complexity of this code. If you increase the complexity, I won't be able to refactor it anymore because I'm struggling to do that even for the current code.</div><div><br></div><div>In addition to that, the MIPS multi-GOT ABI doesn't seem a right design to me. If multi-GOT is in use, only the first GOT is recognized as a real GOT by the dynamic linker, and secondary GOTs are just some sections that simulates GOT. It's too hacky, isn't it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span><span>> I wonder what is the performance penalty you would have to pay when you use the -mxgot<br>
> option. With the option, you'll need three instructions as opposed to a single instruction<br>
> to access an GOT entry. Does that actually make observable difference in performance?<br>
<br>
</span>Regular (without -mxgot) access to GOT requires a single instruction:<br>
<br>
lw  t9,0(gp)<br>
<br>
I was wrong when say about two instructions. With -mxgot option we get<br>
three instructions.<br>
<br>
lui     at,0x0<br>
addu    at,at,gp<br>
lw      t9,0(at)<br>
<br>
In case of MIPS global offset table is used not only to call external<br>
functions / access<br>
external data but for local calls / access under some conditions. So<br>
using -mxgot we can<br>
easily grow the code size and reduce performance.<br></blockquote><div><br></div><div>How much is the actual performance hit?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> ================<br>
> Comment at: ELF/DriverUtils.cpp:31<br>
>  using namespace llvm;<br>
> +using namespace llvm::opt;<br>
>  using namespace llvm::sys;<br>
> ----------------<br>
> Do you need this?<br>
<br>
</span>It's necessary to use the `HelpHidden` flag in the `mips_got_size`<br>
option definition. That allows to hide this option from the list shown<br>
by the `-help`.<br>
<span class="m_-5646197050482019134m_-5431116857277237762m_-7434344183152506402HOEnZb"><font color="#888888"><br>
--<br>
Simon Atanasyan<br>
</font></span></blockquote></div><br></div></div>