-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Cranelift as a backend for clang #9923
Comments
(*) there are some bits of functionality we would have to implement that we don't support today, like: inline assembly (or reject), variadic signatures (or reject), probably other things. Note also that CLIF is at a lower semantic level than LLVM IR specifically wrt aggregate types -- we don't handle structs natively, we expect the producer to lower into primitives and pointers. How much each of these things matters depends on whether you need 100% coverage (e.g. compiling the world or a large project with Clang) or less (compiling your own small code tailor-written with restrictions in mind). |
I wonder how hard it'd be to "reject" everything that's not currently supported, such as inline assembly, but in those cases just gracefully fall back to the LLVM backend. If, say, it works for 95% of the files of a large project (assuming all the stuff that's rejected, like inline assembly, is typically rare), and it just falls back to LLVM for the other 5%, then it's providing roughly 95% of the possible value without new additions to CLIF. |
|
Feature
Since Cranelift is already experimentally working for rustc, I'd like to discuss if it could work for clang, and if so what would be involved. For instance, does rustc_codegen_cranelift turn miri into Cranelift IR, or does it turn LLVM IR into Cranelift IR? From benchmarking my own clang builds, I can see that the backend is a bottleneck and I'd love to see it get faster.
@bjorn3
The text was updated successfully, but these errors were encountered: