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

Restructure staged build / cross-compile architecture for speed #3772

Closed
brson opened this issue Oct 15, 2012 · 2 comments
Closed

Restructure staged build / cross-compile architecture for speed #3772

brson opened this issue Oct 15, 2012 · 2 comments
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Milestone

Comments

@brson
Copy link
Contributor

brson commented Oct 15, 2012

Right now a complete stageN image is composed of artifacts from multiple stages' compilers. This intermixing of stages makes us do more work than we should. It also causes unusual bugs like #3660.

At it's most simple, we want the build to consist of downloading the snapshot compiler and building the binaries once. Right now the closest we can get to that is a stage0 build, but the result of a stage0 build is still using the snapshot compiler. To get a rebuilt compiler you have to build stage1, but building stage1 forces you to rebuild the host libraries.

To recap, we distinguish between the host and target binaries. They live on different places on disk, but they are always built as target binaries, then 'promoted' to the next stage as host binaries.

It looks like this:

bin/ - the 'host' bin directory, /usr/local/bin
  rustc, etc.
lib/ - the 'host' lib directory
  libcore - used by the host toolchain only
  libstd - etc.
  rustc/
    x86_64-unknown-linux-gnu/
       ... target versions of bin/ and lib/

When we create stage0 on disk we drop the snapshot binaries into the stage0 host directories, then build the stage0 target directories. This is not right.

stage0 should be only snapshot binaries, stage1 should be built entirely by stage0, etc. Then a basic build is just download the snapshot and build all the binaries (once) directly to their final on-disk stage1 location. That's it.

Related to #2237

@sanxiyn
Copy link
Member

sanxiyn commented Feb 5, 2013

This is #4638 (which is closed), right?

@brson
Copy link
Contributor Author

brson commented Feb 5, 2013

yes

@brson brson closed this as completed Feb 5, 2013
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 5, 2024
Use Scalar consistently in foreign item emulation

Step 0 of rust-lang#3772

This just makes the code consistent. While we could also go for consistency the other way, that would only allow us to use integers in some cases where we use `Scalar` right now, because `Scalar` can also hold pointers where applicable.

There's also no danger in messing up (even though we do lose some compile-time checks), as `Scalar` knows the size of the integer stored within, so it will check that against the destination when it is written. In fact, this makes the checks much stronger compared with `write_int`, which just checks that the integer fits into the destination size.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

2 participants