Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate placing modules in separate object sections #12455

Closed
alexcrichton opened this issue Feb 21, 2014 · 3 comments
Closed

Investigate placing modules in separate object sections #12455

alexcrichton opened this issue Feb 21, 2014 · 3 comments
Labels
A-codegen Area: Code generation

Comments

@alexcrichton
Copy link
Member

Rust's linkage model means that crates compile to one object file. Linkers today will pull in an entire object file if any symbol from it is used during linkage. This means that if you link to the standard library that you're pulling in the entire library no matter what. This can be circumvented with LTO, but that requires a lot of work on LLVM's part and takes a significant amount of time.

I believe that we can get similar gains through --gc-sections (-dead_strip on osx). All of our object code is emitted to the same section, so this flag currently doesn't eliminate much code. Issue #12140 proposed turning -ffunction-sections on by default, but this causes object size bloat as well as slowing down link times for small crates.

I believe that we may be able to strike a compromise by placing each module's functions in their own section. This reduces the number of sections from thousands to dozens, with the sections being much larger. In this manner, in theory if you don't use any functions from the std::f64 module the entire module can be omitted from linkage.

I would like to investigate the impact of turning these features on by default for all rust compilations. Concretely, this involves two steps:

  1. Instruct LLVM to place each function in a section corresponding to the enclosing module's name.
  2. Pass -Wl,--gc-sections to the linker by default (-Wl,-dead_strip on osx). Also add -C no-gc-sections to turn off passing this flag.

Note that I think we need to be careful to ensure that the linker doesn't GC away metadata for dylibs, but other than that I believe rust code can safely run with --gc-sections for now.

@alexcrichton
Copy link
Member Author

With this turned on by default plus #11560, I believe we can strip out all unused I/O code from executables by default. The thread-local globals would be in their own section, your code wouldn't use anything from that section, and then the section and all its dependencies can then get eliminated.

Also, thinking about this a bit, this should probably start out only turned on for static executables by default, not for dylibs. That would alleviate my concern about metadata.

@alexcrichton
Copy link
Member Author

Closing, we're using ffunction-sections now.

@Boscop
Copy link

Boscop commented Feb 8, 2017

Is fdata-sections used too?

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
fix: rust-lang#12441 False-positive type-mismatch error with generic future

I think the reason is same with rust-lang#11815.
add ```Sized``` bound for ```AsyncBlockTypeImplTrait```.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation
Projects
None yet
Development

No branches or pull requests

2 participants