7 ms·

Is a great deal of actual Rust behavior not fairly intimately tied to LLVM? As far as I know it leaks various LLVM details and much of the documentation about v

Is a great deal of actual Rust behavior not fairly intimately tied to LLVM? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.

chrisseaton 6y ago
I'd find that very surprising and interesting - I can't imagine which semantics could leak from LLVM into a language specification. Can you give some examples?
- Blikkentrekker 6y ago
  For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction https://llvm.org/docs/LangRef.html#getelementptr-instruction I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM's using of signed integers here is apparently nonstandard and what lead to Rust's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-alloc.html https://doc.rust-lang.org/nomicon/vec-alloc.html
  - stouset 6y ago
    I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be. I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.
    - samb1729 6y ago
      Looking at their commenting history, they have a habit of italicising really often, so it's not specific to this topic. It does indeed make a lot of their comments annoying to read without obviously adding any value.
      - codetrotter 6y ago
        > It does indeed make a lot of their comments annoying to read without obviously adding any value I’m going to assume that you mean that the italics don’t add value, and not their comments as a whole. I think your comment could be read either way. Anyways, even so others have since pointed out reasons why the might be used to doing so.
    - balnaphone 6y ago
      This is common nomenclature to enhance readability in fields that have a large number of neologisms and proper nouns, such as some technical domains, medicine, investment banking, and so on. It's particularly useful when names are in the same language as the base language (e.g. in English "Peter" is easily recognized as a name, but "better fish" means something in the language, but can also be used as a proper noun, so using italics for proper nouns serves to disambiguate the intended meaning).
      - deleted 6y ago
        [deleted]
    - tssva 6y ago
      Maybe he is used to writing in MLA style which calls for the titles of software to be italicized just as books, movies, etc are.
    - Blikkentrekker 6y ago
      This is indeed a point of contention among different styles of whether software titles should be italicized. Though the position that they should uniformly be is the minority one, it is certainly used by some outlets with considerable weight, and I believe it to be the consistent one if titles of books and films are too. Some style guides make the even more inconsistent distinction that only titles of video games be italicized, but titles of “application software” not be. I suppose that on H.N., where such software is frequently mentioned, it does stand out more.
      - unanswered 6y ago
        The video games example seems consistent to me; we regularly italicize the names of plays (for example) but not the names of tools and businesses.
        Blikkentrekker 6y ago
        Because tools and businesses are not titles that qualify for intellectual property, a piece of software is. I do not italicize Google the company either, but I do that of Google the search engine. The titles of scientific research papers are also typically italicized.
  - CUViper 6y ago
    Glibc malloc also limits the maximum according to ptrdiff_t, which is effectively the same as Rust isize.
  - chrisseaton 6y ago
    getelementptr is just some pointer arithmetic - all backends can do that. And using signed integers is unusual yes, but again all backends (obviously) also support signed integers.
    - steveklabnik 6y ago
      IMHO, "Just some pointer arithmetic" is selling it a bit short. There's a lot of stuff there around provenance that matters, that is, there's a reason this is an intrinsic and not just a subtraction after casting both to an int. (I agree on the signed integer thing though.)
monocasa 6y ago
I don't think much of the stable functionality exposes llvm internals. Part of stabilizing is removing the llvm leaks into the language.
dagmx 6y ago
Potentially but there are alternative backends like cranelift so it's unlikely anything major is tied to just LLVM anymore
steveklabnik 6y ago
IMHO, "great deal" is overemphasizing it. There are some things, yes, but they are mostly smaller, more niche details that are even probably things we'd choose ourselves in many cases. That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.
- masklinn 6y ago
  > Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias. I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.
  - steveklabnik 6y ago
    The latter, you're right, I did make a mistake here. I was thinking of it as "Rust doesn't just do whatever LLVM does, see, we have semantics and LLVM compiles them wrong, so this is an example of that" but I forgot that actually, we do specify "this follows what LLVM does" currently, and the miscompilation is just a plain bug. Extra embarrassing because IIRC I was the one who made the PR saying that. The former though is an area of significant divergence between Rust and C++ semantics, and LLVM directly following C++ semantics.
    - masklinn 6y ago
      > The former though is an area of significant divergence between Rust and C++ semantics, and LLVM blindly following C++ semantics. Ah I must have missed that, I thought you were talking about only one thing (since IIRC the noalias miscompilation is due to loop unrolling?)
      - steveklabnik 6y ago
        I don't know the root cause of the noalias miscompilation, the thing I was referring to is https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728 TL;DR: C++ says that an infinite loop with no side effects is UB, Rust does not. Empty loops in Rust will disappear entirely when they should really loop forever. (I edited my comment slightly because, re-reading, "blindly" sounds too negative.)

chrisseaton 6y ago

I'd find that very surprising and interesting - I can't imagine which semantics could leak from LLVM into a language specification. Can you give some examples?

Blikkentrekker 6y ago
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction https://llvm.org/docs/LangRef.html#getelementptr-instruction I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM's using of signed integers here is apparently nonstandard and what lead to Rust's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-alloc.html https://doc.rust-lang.org/nomicon/vec-alloc.html
- stouset 6y ago
  I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be. I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.
  - samb1729 6y ago
    Looking at their commenting history, they have a habit of italicising really often, so it's not specific to this topic. It does indeed make a lot of their comments annoying to read without obviously adding any value.
    - codetrotter 6y ago
      > It does indeed make a lot of their comments annoying to read without obviously adding any value I’m going to assume that you mean that the italics don’t add value, and not their comments as a whole. I think your comment could be read either way. Anyways, even so others have since pointed out reasons why the might be used to doing so.
  - balnaphone 6y ago
    This is common nomenclature to enhance readability in fields that have a large number of neologisms and proper nouns, such as some technical domains, medicine, investment banking, and so on. It's particularly useful when names are in the same language as the base language (e.g. in English "Peter" is easily recognized as a name, but "better fish" means something in the language, but can also be used as a proper noun, so using italics for proper nouns serves to disambiguate the intended meaning).
    - deleted 6y ago
      [deleted]
  - tssva 6y ago
    Maybe he is used to writing in MLA style which calls for the titles of software to be italicized just as books, movies, etc are.
  - Blikkentrekker 6y ago
    This is indeed a point of contention among different styles of whether software titles should be italicized. Though the position that they should uniformly be is the minority one, it is certainly used by some outlets with considerable weight, and I believe it to be the consistent one if titles of books and films are too. Some style guides make the even more inconsistent distinction that only titles of video games be italicized, but titles of “application software” not be. I suppose that on H.N., where such software is frequently mentioned, it does stand out more.
    - unanswered 6y ago
      The video games example seems consistent to me; we regularly italicize the names of plays (for example) but not the names of tools and businesses.
      - Blikkentrekker 6y ago
        Because tools and businesses are not titles that qualify for intellectual property, a piece of software is. I do not italicize Google the company either, but I do that of Google the search engine. The titles of scientific research papers are also typically italicized.
- CUViper 6y ago
  Glibc malloc also limits the maximum according to ptrdiff_t, which is effectively the same as Rust isize.
- chrisseaton 6y ago
  getelementptr is just some pointer arithmetic - all backends can do that. And using signed integers is unusual yes, but again all backends (obviously) also support signed integers.
  - steveklabnik 6y ago
    IMHO, "Just some pointer arithmetic" is selling it a bit short. There's a lot of stuff there around provenance that matters, that is, there's a reason this is an intrinsic and not just a subtraction after casting both to an int. (I agree on the signed integer thing though.)

monocasa 6y ago

I don't think much of the stable functionality exposes llvm internals. Part of stabilizing is removing the llvm leaks into the language.

dagmx 6y ago

Potentially but there are alternative backends like cranelift so it's unlikely anything major is tied to just LLVM anymore

steveklabnik 6y ago

IMHO, "great deal" is overemphasizing it. There are some things, yes, but they are mostly smaller, more niche details that are even probably things we'd choose ourselves in many cases. That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.

masklinn 6y ago
> Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias. I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.
- steveklabnik 6y ago
  The latter, you're right, I did make a mistake here. I was thinking of it as "Rust doesn't just do whatever LLVM does, see, we have semantics and LLVM compiles them wrong, so this is an example of that" but I forgot that actually, we do specify "this follows what LLVM does" currently, and the miscompilation is just a plain bug. Extra embarrassing because IIRC I was the one who made the PR saying that. The former though is an area of significant divergence between Rust and C++ semantics, and LLVM directly following C++ semantics.
  - masklinn 6y ago
    > The former though is an area of significant divergence between Rust and C++ semantics, and LLVM blindly following C++ semantics. Ah I must have missed that, I thought you were talking about only one thing (since IIRC the noalias miscompilation is due to loop unrolling?)
    - steveklabnik 6y ago
      I don't know the root cause of the noalias miscompilation, the thing I was referring to is https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728 TL;DR: C++ says that an infinite loop with no side effects is UB, Rust does not. Empty loops in Rust will disappear entirely when they should really loop forever. (I edited my comment slightly because, re-reading, "blindly" sounds too negative.)