You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current LLVM backend for rustc is very good at optimizing functions. However it is not the fastest, even with optimizations disabled. When compiling in release mode this is not a big problem, but during development this can be annoying. Cranelift has the potential to improve compilation time, as it is optimized for compilation time as opposed to being optimized for good optimizations like LLVM. Over the course of the past ~1.5 year I have been working on a Cranelift based codegen backend for rustc (rustc_codegen_cranelift or cg_clif for short). It is currently complete enough to compile many programs. While there are cases where LLVM is faster, Cranelift is already faster than LLVM in many cases.
Rustc_codegen_cranelift is currently at a point where it may make sense to talk about bringing support in tree. This meeting proposal is about talking if we do want this and to talk about the future of rustc_codegen_cranelift in general.
This issue corresponds to a meeting proposal for the compiler team steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.
Comment policy
These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).
The text was updated successfully, but these errors were encountered:
Meeting proposal info
Summary
The current LLVM backend for rustc is very good at optimizing functions. However it is not the fastest, even with optimizations disabled. When compiling in release mode this is not a big problem, but during development this can be annoying. Cranelift has the potential to improve compilation time, as it is optimized for compilation time as opposed to being optimized for good optimizations like LLVM. Over the course of the past ~1.5 year I have been working on a Cranelift based codegen backend for rustc (rustc_codegen_cranelift or cg_clif for short). It is currently complete enough to compile many programs. While there are cases where LLVM is faster, Cranelift is already faster than LLVM in many cases.
Rustc_codegen_cranelift is currently at a point where it may make sense to talk about bringing support in tree. This meeting proposal is about talking if we do want this and to talk about the future of rustc_codegen_cranelift in general.
More details and meeting outline in this hackmd
About this issue
This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.
Comment policy
These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).
The text was updated successfully, but these errors were encountered: