[PATCH] D152279: [Driver] Default -msmall-data-limit= to 0

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D152279#4414574 <https://reviews.llvm.org/D152279#4414574>, @hiraditya wrote:

> In D152279#4406896 <https://reviews.llvm.org/D152279#4406896>, @MaskRay wrote:
>
>> In D152279#4405901 <https://reviews.llvm.org/D152279#4405901>, @asb wrote:
>>
>>> One of the key things we've been discussing on this at the LLVM call is that we probably want to keep the small data limit for embedded targets.
>>
>> It'd be useful to hear from some concrete embedded target users, whether they customize `-msmall-data-limit=`, whether they are happy with `-msmall-data-limit=8`, or whether they are just unaware of this threshold.
>>
>> If an embedded system typically customizes compiler driver options a lot, I think they can consider adding `-msmall-data-limit=` (with a value suitable for their use cases) in a configuration file <https://clang.llvm.org/docs/UsersManual.html#configuration-files>, not letting their use cases dictate Linux systems.
>>
>> I putting up the patch partly came from my stance finding UX of this option is really confusing and misleading. I wish that the embedded target users can give me compelling arguments to keep `-msmall-data-limit=8` (and not another value).
>
> The default of 8 is probably to make it consistent with gcc. Here is text from man gcc <https://man7.org/linux/man-pages/man1/gcc.1.html>
>
>   -msmall-data
>   -mlarge-data
>       When -mexplicit-relocs is in effect, static data is accessed
>       via gp-relative relocations.  When -msmall-data is used,
>       objects 8 bytes long or smaller are placed in a small data
>       area (the ".sdata" and ".sbss" sections) and are accessed via
>       16-bit relocations off of the $gp register.  This limits the
>       size of the small data area to 64KB, but allows the variables
>       to be directly accessed via a single instruction.
>   
>       The default is -mlarge-data.  With this option the data area
>       is limited to just below 2GB.  Programs that require more
>       than 2GB of data must use "malloc" or "mmap" to allocate the
>       data in the heap instead of in the program's data segment.
>   
>       When generating code for shared libraries, -fpic implies
>       -msmall-data and -fPIC implies -mlarge-data.

This GCC documentation is about the rx port. GCC's alpha and rx ports support `-msmall-data`, but RISC-V just says:

> -msmall-data-limit=n   Put global and static data smaller than n bytes into a special section (on some targets).

Matching GCC behaviors give many benefits and Clang does this a lot, especially in cases where matching/not-matching doesn't make much difference (i.e. we don't need to have an opinion).
However, RISC-V `-msmall-data-limit=` is probably a case warranting a difference.
The global pointer relaxation has a very limited value (benchmarked by multiple parties, including a party which implemented this feature in the GNU toolchain: even they can only say the optimization only applies to very specific projects).
The default value is confusing: as explained by the summary.

I suspect that `-msmall-data-limit=8` is too conservative, maybe 16 would be better, I don't know. I think global pointer relaxation users should toggle this by themselves, not relying on `0` or `8` default decided by a bunch of strange conditions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152279/new/

https://reviews.llvm.org/D152279