aengelke wrote: > I think it is relatively common for string tables to end up producing a lot > of relocations in shared objects.
Yes, and this is a problem, which we try to avoid by using EnumStrings, StringTable, string-structs, etc. in our code base. We shouldn't have large tables that require dynamic relocations inside the library. As a side effect, not using string tables like this also reduces the binary size. Cf. also our [CodingStandards](https://llvm.org/docs/CodingStandards.html#avoid-pointers-in-global-static-constants). > Are there particular situations where the number of relocations is causing an > issue? Dynamic relocations are costly for every user of LLVM-as-a-library when consuming a PIC-build (e.g., LLVM as a shared library), as they add a significant startup cost (especially the page faults, but also applying the relocations) and permanent memory usage. They are also add significant overhead when running tests with a dylib build. > What percentage of the total is the 9kb ~0.7% of .data.rel.ro of an all-target libLLVM.so (context: 71% of .data.rel.ro are vtables). As usual with LLVM, the individual changes have little-to-no benefit on measurable times, but the accumulated benefits of several tiny changes like this has. > Could you not achieve the same result by changing the StringRef members to be > char [N]? Yes, but I would expect a somewhat larger increase the binary size, as N needs to be the maximum string length of each table. I'm not particularly attached to the way this PR solves the problem (I don't have time to address comments/get this over the finish line), so if you prefer some other approach, this is fine for me. However, do note that most LLVM users don't target ARM and that every LLVM build (even with the ARM target disabled) will include these tables. https://github.com/llvm/llvm-project/pull/206937 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
