[PATCH] Don't access items in .sdata section using gp-relative addressing when target is NaCl.

[Mark Seaborn]

On 10 June 2014 06:14, Sasa Stankovic <Sasa.Stankovic at imgtec.com> wrote:

> > Presumably the reason that UseSmallSection is disabled for Linux is that
> LLVM is assuming that it might be being used with Gold?
>
> It isn't related to Gold because apart from PNaCl, MIPS Gold is not used
> anywhere else; MIPS Gold isn't even committed to the FSF binutils - the
> patch is still in review on binutils mailing list.
>
> I suppose that the reason why it's disabled in Linux is because
> gp-relative addressing can only address 64K area (MIPS has 16-bit
> load/store offsets). That's probably why it's never used for PIC code (both
> Linux and non-Linux), because in PIC code .got section is also accessed
> using gp-relative addressing, so that leaves even less space for data items
> to be accessed using gp-relative addressing.


Yes, that explanation makes a lot of sense.

The sdata section is a rather curious feature.  It seems to be based on the
assumption that if some variables are each individually small, the total
size of those variables (across all .o files) will be less than 64k.  This
assumption is... optimistic. :-)

Would it make sense to turn off use of sdata by default, and have it only
enabled by a compiler flag or llc flag?  That would be cleaner and is not
very difficult to do.  It should come with a warning like "this is an
optimisation that might cause moderate-sized programs to fail to link".

BTW, have you looked at the GlobalMerge pass
(lib/Transforms/Scalar/GlobalMerge.cpp)?  That is used on ARM and gives a
similar kind of optimisation to the MIPS sdata section.  It will reuse the
computation of a base address within the data segment for multiple
variables, rather than computing a data segment address for each variable
that's referenced.  GlobalMerge is a more robust way of doing this
optimisation than sdata, though it only works when the referenced variables
are within the same compilation unit being compiled by llc.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140610/fa1e1769/attachment.html>