Hacker News new | past | comments | ask | show | jobs | submit login

Do these changes require/imply upstreaming rust's llvm changes? Is there any resistance for llvm to take the changes necessary?



Today Rust only has a [few patches to LLVM](https://github.com/rust-lang/llvm/tree/rust). One is for Android stack overflow detection using a mechanism that upstream isn't fond of (split stacks), the other an optimization not required for correctness.

The Android patch can be eliminated someday with stack probes (though it's not clear upstream wants those either).

Emscripten support though - at least in the short term - is going to bring in the [emscripten LLVM 'fastcomp' backend](https://github.com/kripken/emscripten-fastcomp) that translates LLVM IR to JS. This patch has no hope of being upstreamed and will impose significant maintenance burden on both Rust and Emscripten as long as its in tree. This solution should be short-lived though as we will transition to either the upstream LLVM->wasm backend or a new Rust MIR->wasm backend.

So I think the answer to your question is 'no'.


I've been told that the LLVM branch I linked to is 'the most wrong branch you possibly could have linked to'.

This is the right one: https://github.com/rust-lang/llvm/tree/rust-llvm-2016-03-13

Patches are mostly backported from upstream or optimizations.


To those in this thread, note that brson is the author of this blog post, as well as the primary maintainer of rustup, and has had his eyes on a web target for Rust for some years now.


We generally try to upstream our patches, and they've been generally accepted. IIRC, our current fork is very close to LLVM head. We also do support building with stock LLVM, though it may have bugs for the stuff that wasn't patched at the time that release was made, of course.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: