33f33bb7d6932ca2432bab8e589bb4728dd1d9c6

Normally, the linker will pull in any compilation unit (aka .c file) from a static lib (such as our shared util code) that is depended on by the code linking against it. Since that code is already compiled, the .text section is allowed to jump anywhere in .text, and the compiler can't garbage collect unused functions inside of a compile unit. Teasing callgraphs apart so that normal compilation-unit-level GCing can reduce driver size hurts the logical organization of the code and is difficult. As an example, once I'd split the format pack/unpack tables, I had to split out util_format_read/write() from util_format.c to avoid pulling in pack/unpack. But even then it didn't help, because it turns out turnip's pack calls pull in util_format_bptc.c for bptc packing, but that file also includes the unpack impls, and those internally call util_format_unpack, and thus we pulled in all of unpack. Splitting all of this to separate files makes code harder to find and maintain, and is a waste of dev time. By setting these compiler flags, the compiler puts each function and data symbol in a separate ELF section and the linker can then safely GC unused text and data sections from a compile unit that gets pulled in. There's a bit of a space cost due to having those separate sections, but it ends up being a huge win in disk space on my personal release driver builds: - i965_dri.so -213k - x86 gallium dri.so -430k - libvulkan_intel.so -272k - aarch64 gallium dri.so -330k - libvulkan_freedreno.so -783k No difference on iris drawoverhead -compat -test 1 on my skylake (n=60) Effect on debugoptimized build times (n=5) touch nir_lower_io.c build time (bfd) +15.999% +/- 3.80377% touch freedreno fd6_gmem.c build time (bfd) +13.5294% +/- 4.86363% touch nir_lower_io.c build time (lld) no change touch freedreno fd6_gmem.c build time (lld) +2.45375% +/- 2.2383% Reviewed-by: Eric Engestrom <eric@engestrom.ch> Acked-by: Adam Jackson <ajax@redhat.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5739>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `Freenode's #dri-devel <irc://chat.freenode.net#dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.
Description
Languages
C
75.3%
C++
18.2%
Python
2.7%
Assembly
1.5%
Rust
1.2%
Other
0.9%