<br><br>On Tuesday, April 4, 2017, Simon Atanasyan via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Sat, Apr 1, 2017 at 4:20 AM, Rui Ueyama via Phabricator<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'reviews@reviews.llvm.org')">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>
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.</blockquote><div><br></div><div>Limited range for immediates is true for most RISC architectures. Why is MIPS so special here? What do other arches do?</div><div><br></div><div>-- Sean Silva</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
MIPS specific<br>
fields from the `SymbolBody` class.<br>
<br>
> 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>
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>
<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>
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>
<br>
--<br>
Simon Atanasyan<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'llvm-commits@lists.llvm.org')">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</blockquote>