Set kernel default visibility to hidden #3060
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/3060
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit c84fa42 with merge base c73bfc0 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D56167833 |
kirklandsign
force-pushed
the
export-D56167833
branch
from
f865987 to
3f1db23
Compare
kirklandsign
added a commit
to kirklandsign/executorch
that referenced
this pull request
Apr 16, 2024
Summary: When we compile the kernel into a shared library, we don't know whether the definition of kernel implementation symbol can be dropped or not based on op registry. The kernel itself is just a normal function and the user can find it. We set its visibility to hidden by default. Then these kernels are gone when we do `objdump -TC` This reduces binary size. Differential Revision: D56167833
|
This pull request was exported from Phabricator. Differential Revision: D56167833 |
kirklandsign
added a commit
to kirklandsign/executorch
that referenced
this pull request
Apr 16, 2024
Summary: When we compile the kernel into a shared library, we don't know whether the definition of kernel implementation symbol can be dropped or not based on op registry. The kernel itself is just a normal function and the user can find it. We set its visibility to hidden by default. Then these kernels are gone when we do `objdump -TC` This reduces binary size. --- This is not done in fbcode so far. When we compile in fbcode, seems that all dependency libraries is compiled into shared library, not static library. For example, op tests depends on op implementation through shared library. In that case, the hidden symbols are not exposed and could cause link time failure. In xplat, these dependencies are set to static libraries so it has no impact. Only when we explicitly build a shared library (for android), we hide the symbols and rely on op registry to store the impl. Differential Revision: D56167833
kirklandsign
force-pushed
the
export-D56167833
branch
from
3f1db23 to
5c39639
Compare
|
This pull request was exported from Phabricator. Differential Revision: D56167833 |
kirklandsign
added a commit
to kirklandsign/executorch
that referenced
this pull request
Apr 16, 2024
Summary: When we compile the kernel into a shared library, we don't know whether the definition of kernel implementation symbol can be dropped or not based on op registry. The kernel itself is just a normal function and the user can find it. We set its visibility to hidden by default. Then these kernels are gone when we do `objdump -TC` This reduces binary size. --- This is not done in fbcode so far. When we compile in fbcode, seems that all dependency libraries is compiled into shared library, not static library. For example, op tests depends on op implementation through shared library. In that case, the hidden symbols are not exposed and could cause link time failure. In xplat, these dependencies are set to static libraries so it has no impact. Only when we explicitly build a shared library (for android), we hide the symbols and rely on op registry to store the impl. --- This applies to internal build only for now. We will re-visit this for OSS later. It's a step needed to make use of selective build for building shared library (android use case mainly) Differential Revision: D56167833
kirklandsign
force-pushed
the
export-D56167833
branch
from
5c39639 to
591d491
Compare
|
This pull request was exported from Phabricator. Differential Revision: D56167833 |
dbort
approved these changes
Apr 16, 2024
kirklandsign
added a commit
to kirklandsign/executorch
that referenced
this pull request
Apr 16, 2024
Summary: When we compile the kernel into a shared library, we don't know whether the definition of kernel implementation symbol can be dropped or not based on op registry. The kernel itself is just a normal function and the user can find it. We set its visibility to hidden by default. Then these kernels are gone when we do `objdump -TC` This reduces binary size. --- This is not done in fbcode so far. When we compile in fbcode, seems that all dependency libraries is compiled into shared library, not static library. For example, op tests depends on op implementation through shared library. In that case, the hidden symbols are not exposed and could cause link time failure. In xplat, these dependencies are set to static libraries so it has no impact. Only when we explicitly build a shared library (for android), we hide the symbols and rely on op registry to store the impl. --- This applies to internal build only for now. We will re-visit this for OSS later. It's a step needed to make use of selective build for building shared library (android use case mainly) Reviewed By: dbort Differential Revision: D56167833
kirklandsign
force-pushed
the
export-D56167833
branch
from
591d491 to
e411228
Compare
|
This pull request was exported from Phabricator. Differential Revision: D56167833 |
Summary: When we compile the kernel into a shared library, we don't know whether the definition of kernel implementation symbol can be dropped or not based on op registry. The kernel itself is just a normal function and the user can find it. We set its visibility to hidden by default. Then these kernels are gone when we do `objdump -TC` This reduces binary size. --- This is not done in fbcode so far. When we compile in fbcode, seems that all dependency libraries is compiled into shared library, not static library. For example, op tests depends on op implementation through shared library. In that case, the hidden symbols are not exposed and could cause link time failure. In xplat, these dependencies are set to static libraries so it has no impact. Only when we explicitly build a shared library (for android), we hide the symbols and rely on op registry to store the impl. --- This applies to internal build only for now. We will re-visit this for OSS later. It's a step needed to make use of selective build for building shared library (android use case mainly) Reviewed By: dbort Differential Revision: D56167833
kirklandsign
force-pushed
the
export-D56167833
branch
from
e411228 to
c84fa42
Compare
|
This pull request was exported from Phabricator. Differential Revision: D56167833 |
|
This pull request has been merged in 54f9f3e. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
When we compile the kernel into a shared library, we don't know whether the definition of kernel implementation symbol can be dropped or not based on op registry. The kernel itself is just a normal function and the user can find it. We set its visibility to hidden by default. Then these kernels are gone when we do
objdump -TCThis reduces binary size.
Differential Revision: D56167833