Skip to content

Minimize exported symbols of libtriton#9922

Merged
neildhar merged 1 commit into
mainfrom
neildhar/pr9922
Apr 24, 2026
Merged

Minimize exported symbols of libtriton#9922
neildhar merged 1 commit into
mainfrom
neildhar/pr9922

Conversation

@neildhar
Copy link
Copy Markdown
Collaborator

@neildhar neildhar commented Apr 3, 2026

When extensions are not enabled, libtriton only needs to export a single
symbol _PyInit_libtriton. However, currently:

  1. On macOS, we export all LLVM symbols since we don't have
    something like exclude-libs.
  2. On Linux, despite exclude-libs we still export ~100 symbols, mostly
    from template instantiations.

Maintaining an explicit symbol export list ensure the interface is very
narrowly scoped, which:

  1. Minimizes the chance of symbol conflicts. This is especially a
    problem on macOS, where we currently export everything, and cpython
    by default opens libraries with RTLD_GLOBAL (Default dlopenflags inconsistent between Linux and macOS python/cpython#137880).
  2. Allows the linker to strip dead code better.
  3. Reduces the size of the symbol table. On macOS arm64, this change
    reduces the size of a stripped libtriton from 133.7 MiB to 113.6 MiB.

@neildhar neildhar force-pushed the neildhar/pr9922 branch 2 times, most recently from e9df680 to fc8d268 Compare April 23, 2026 20:52
Copy link
Copy Markdown
Collaborator

@Mogball Mogball left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hero we need but don't deserve

When extensions are not enabled, libtriton only needs to export a single
symbol `_PyInit_libtriton`. However, currently:
1. On macOS, we export all LLVM symbols since we don't have
   something like `exclude-libs`.
2. On Linux, despite `exclude-libs` we still export ~100 symbols, mostly
   from template instantiations.

Maintaining an explicit symbol export list ensure the interface is very
narrowly scoped, which:
1. Minimizes the chance of symbol conflicts. This is especially a
   problem on macOS, where we currently export everything, and cpython
   by default opens libraries with RTLD_GLOBAL (python/cpython#137880).
2. Allows the linker to strip dead code better.
3. Reduces the size of the symbol table. On macOS arm64, this change
   reduces the size of a stripped libtriton from 133.7 MiB to 113.6 MiB.
@neildhar neildhar marked this pull request as ready for review April 23, 2026 21:03
@neildhar neildhar requested a review from ptillet as a code owner April 23, 2026 21:03
Copy link
Copy Markdown
Collaborator

@ThomasRaoux ThomasRaoux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@neildhar neildhar enabled auto-merge (squash) April 23, 2026 21:18
@neildhar neildhar merged commit fdfded1 into main Apr 24, 2026
16 of 18 checks passed
@neildhar neildhar deleted the neildhar/pr9922 branch April 24, 2026 11:33
abrown added a commit to abrown/triton that referenced this pull request May 11, 2026
This change proposes a split into two libraries:
- `libtritoncore.so` which would (eventually) contain only Triton code,
  nothing vendor-specific; all of these symbols are exported
- `libtriton.so` which `RPATH`-depends on `libtritoncore.so` and
  includes all of vendor-specific code with the Python bindings; these
  symbols are all hidden (see triton-lang#9922).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants