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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
