5 ms·

LLVM devs don't really care about Rust. They haven't fixed noalias in years, there isn't still a freeze intrinsic in the IR, the LLVM-IR semantics are often not

LLVM devs don't really care about Rust. They haven't fixed noalias in years, there isn't still a freeze intrinsic in the IR, the LLVM-IR semantics are often not documented enough for the Rust compiler to know whether it is generating IR that has UB or not... I see a couple of Rust developers working on LLVM almost full-time (like nikic), but there should be more. The Rust language needs to become a more important stakeholder, and for that it needs more paid full-time LLVM developers, infinite loops are UB in LLVM-IR...

ncmncm 7y ago
LLVM developers are focused on the needs of (literally!) millions of C and C++ programmers. Until you can point to a few hundred-thousand production Rust coders, or get somebody with deep pockets to depend on it, Rust is just not important enough. The solution is to fund your own LLVM developers. If you can't raise the money to pay them, who should? People with deep pockets are typically advised not to depend on unsupported infrastructure. It is hard and, often, unwise to argue with such advice. It is still early days. Give it ten years: Rust will either have taken off or sunk, by then. Maybe somewhere in those years there will be some new hotness to jump on instead.
- Hello71 7y ago
  Rust has in fact had almost 10 years.
  - Jweb_Guru 7y ago
    The Rust of ten years ago bears almost no resemblance to the Rust of today. Its history is interesting to people involved in the project, but it wasn't really used seriously until 1.0 was released.
    - ChrisSD 7y ago
      I make it 9 years since the first release and 4 years since the first stable version (aka 1.0). Either way it's a short time in which to gain acceptance anywhere near the level of C++ so it's not surprising it hasn't. Although companies (including Microsoft and some Google teams) are just starting to take it seriously.
      - imtringued 7y ago
        It's not a short time. C++ is only 34 years old and back them there were fewer developers than today.
        hyperman1 7y ago
        C with classes, which would be comparable to pre 1.0 rust, started in 1979, so 40 years ago. The first commercial C++ and the book were in 1985 and 34 years ago. I'd guess that's a good 1.0 milestone, comparable with rust's 4 years.
  - ncmncm 7y ago
    Ten more years. It takes a long, long time for a language to gain maturity, and the competition (except C :P) is improving the whole time.
    - dmitrygr 7y ago
      > and the competition (except C :P) is improving the whole time. https://en.wikipedia.org/wiki/C18_(C_standard_revision) https://en.wikipedia.org/wiki/C18_(C_standard_revision)
      - arcticbull 7y ago
        "C18 is a “bugfix release” of the C standard. Whereas the intention of the C working group (WG14) has been that this release does not introduce normative changes (but one)..."
        dmitrygr 7y ago
        C11 added a lot of features though
  - leshow 7y ago
    It's not really fair to count pre-1.0, it's only been 4-5 years
sanxiyn 7y ago
Another: Rust is de facto QA service for LLVM's support for overflow intrinsics. Unlike noalias they continue to work, but in practice they continue to work only due to fixes from Rust project.
- ridiculous_fish 7y ago
  Why doesn't Swift play that role?
  - sanxiyn 7y ago
    In fact I am not sure why... I am just reporting the experience. Maybe because of architectural coverage, because while bugs also happen in architecture-independent optimizations, more bugs happen in, say, PowerPC backend. Edit: Another possibility is difference between how often Rust and Swift update to LLVM trunk. Both have LLVM fork pinned to specific version updated from time to time and I guess the first to update gets all the bugs.
  - masklinn 7y ago
    Possibly because Swift being more of an application language, Swift codebases in general have very little use for overflowing operations?
    - sanxiyn 7y ago
      No, it's not that. All Swift arithmetic compiles to overflow intrinsics.
wyldfire 7y ago
IMO a lot of LLVM bug fixes are driven by particular devs motivated to fix issues in the area that they contributed or that they're willing to take the time to investigate. If your bug happens to hit a use case important to flagships like XCode or Android -- or any of the internal projects at Apple or Google, you have a much better chance of seeing it fixed. Unless your bug shows a clear regression and is interesting enough to be a release blocker, it probably won't get prioritized. OTOH if you supply a patch with your bug report, it probably has a decent chance of getting accepted. LLVM doesn't not care about rust. It's just not a pet project of a heavy hitter yet. So rust devs dig down and find llvm bugs. But a best case scenario would be a "llvm developer" working for Google/Apple/Mozilla who will prioritize features and fixes impacting rust. But that's not necessarily better than another "rust Dev" willing to dig down and find llvm bugs. I'm not knocking LLVM, I think it's a great community. Just strikes me as more of a BYO-bugfix kinda gang.
ndesaulniers 7y ago
> LLVM devs don't really care about Rust. [citation needed] (I have thousands of lines in both) > They haven't fixed noalias in years, I think you fail to understand the complexities of TBAA, which are and have been working on for a long time. It's a lot of work frankly. > there isn't still a freeze intrinsic in the IR, the LLVM-IR semantics are often not documented enough for the Rust compiler to know whether it is generating IR that has UB or not... It's important to have more languages target LLVM to flush these out. Things aren't intentionally undocumented; more like no one has really thought that hard about edge cases and interactions. And if there's only a few front ends generating similar IR, who will expose those dark corners?

ncmncm 7y ago

LLVM developers are focused on the needs of (literally!) millions of C and C++ programmers. Until you can point to a few hundred-thousand production Rust coders, or get somebody with deep pockets to depend on it, Rust is just not important enough. The solution is to fund your own LLVM developers. If you can't raise the money to pay them, who should? People with deep pockets are typically advised not to depend on unsupported infrastructure. It is hard and, often, unwise to argue with such advice. It is still early days. Give it ten years: Rust will either have taken off or sunk, by then. Maybe somewhere in those years there will be some new hotness to jump on instead.

Hello71 7y ago
Rust has in fact had almost 10 years.
- Jweb_Guru 7y ago
  The Rust of ten years ago bears almost no resemblance to the Rust of today. Its history is interesting to people involved in the project, but it wasn't really used seriously until 1.0 was released.
  - ChrisSD 7y ago
    I make it 9 years since the first release and 4 years since the first stable version (aka 1.0). Either way it's a short time in which to gain acceptance anywhere near the level of C++ so it's not surprising it hasn't. Although companies (including Microsoft and some Google teams) are just starting to take it seriously.
    - imtringued 7y ago
      It's not a short time. C++ is only 34 years old and back them there were fewer developers than today.
      - hyperman1 7y ago
        C with classes, which would be comparable to pre 1.0 rust, started in 1979, so 40 years ago. The first commercial C++ and the book were in 1985 and 34 years ago. I'd guess that's a good 1.0 milestone, comparable with rust's 4 years.
- ncmncm 7y ago
  Ten more years. It takes a long, long time for a language to gain maturity, and the competition (except C :P) is improving the whole time.
  - dmitrygr 7y ago
    > and the competition (except C :P) is improving the whole time. https://en.wikipedia.org/wiki/C18_(C_standard_revision) https://en.wikipedia.org/wiki/C18_(C_standard_revision)
    - arcticbull 7y ago
      "C18 is a “bugfix release” of the C standard. Whereas the intention of the C working group (WG14) has been that this release does not introduce normative changes (but one)..."
      - dmitrygr 7y ago
        C11 added a lot of features though
- leshow 7y ago
  It's not really fair to count pre-1.0, it's only been 4-5 years

sanxiyn 7y ago

Another: Rust is de facto QA service for LLVM's support for overflow intrinsics. Unlike noalias they continue to work, but in practice they continue to work only due to fixes from Rust project.

ridiculous_fish 7y ago
Why doesn't Swift play that role?
- sanxiyn 7y ago
  In fact I am not sure why... I am just reporting the experience. Maybe because of architectural coverage, because while bugs also happen in architecture-independent optimizations, more bugs happen in, say, PowerPC backend. Edit: Another possibility is difference between how often Rust and Swift update to LLVM trunk. Both have LLVM fork pinned to specific version updated from time to time and I guess the first to update gets all the bugs.
- masklinn 7y ago
  Possibly because Swift being more of an application language, Swift codebases in general have very little use for overflowing operations?
  - sanxiyn 7y ago
    No, it's not that. All Swift arithmetic compiles to overflow intrinsics.

wyldfire 7y ago

IMO a lot of LLVM bug fixes are driven by particular devs motivated to fix issues in the area that they contributed or that they're willing to take the time to investigate. If your bug happens to hit a use case important to flagships like XCode or Android -- or any of the internal projects at Apple or Google, you have a much better chance of seeing it fixed. Unless your bug shows a clear regression and is interesting enough to be a release blocker, it probably won't get prioritized. OTOH if you supply a patch with your bug report, it probably has a decent chance of getting accepted. LLVM doesn't not care about rust. It's just not a pet project of a heavy hitter yet. So rust devs dig down and find llvm bugs. But a best case scenario would be a "llvm developer" working for Google/Apple/Mozilla who will prioritize features and fixes impacting rust. But that's not necessarily better than another "rust Dev" willing to dig down and find llvm bugs. I'm not knocking LLVM, I think it's a great community. Just strikes me as more of a BYO-bugfix kinda gang.

ndesaulniers 7y ago

> LLVM devs don't really care about Rust. [citation needed] (I have thousands of lines in both) > They haven't fixed noalias in years, I think you fail to understand the complexities of TBAA, which are and have been working on for a long time. It's a lot of work frankly. > there isn't still a freeze intrinsic in the IR, the LLVM-IR semantics are often not documented enough for the Rust compiler to know whether it is generating IR that has UB or not... It's important to have more languages target LLVM to flush these out. Things aren't intentionally undocumented; more like no one has really thought that hard about edge cases and interactions. And if there's only a few front ends generating similar IR, who will expose those dark corners?