News for hackers. Stuff that matters.
Re:Introducing MIR by hacker_9 on Wednesday April 27, 2016 @12:55PM (#11582195)
It's not a bug, and the answer is provided in the link:

"Faster execution time. You may have noticed that in the new compiler pipeline, optimization appears twice. That’s no accident: previously, the compiler relied solely on LLVM to perform optimizations, but with MIR, we can do some Rust-specific optimizations before ever hitting LLVM – or, for that matter, before monomorphizing code. Rust’s rich type system should provide fertile ground for going beyond LLVM’s optimizations."

Re:Introducing MIR by kibwen on Wednesday April 27, 2016 @01:15PM (#11582376)
There's still an implicit question there, concerning why one would choose to develop a new IR rather than enhancing LLVM (the latter of which the Rust devs (and especially the Swift devs) have had years of experience doing). Though I'm not trying to suggest that Rust made the wrong decision or is suffering from NIH, because MIR is great, and there's no reason to suspect that shoving absolutely everything down into LLVM is necessarily a tractable solution. I'm just curious which Rust-specific and Swift-specific optimizations these IRs enable above and beyond LLVM IR's capabilities, and what that says about each source language in turn (especially if we regard LLVM IR as a proxy for C, being LLVM's original target).
Re:Introducing MIR by rayiner on Wednesday April 27, 2016 @01:50PM (#11582748)
It's easiest to do optimizations on an IR that has the appropriate level of granularity. If you're trying to optimize address calculations, it's easier to work with something like LLVM's getelementptr, which represents an address calculation as one IR node, than a C-level IR (where the address calculation would be implicit in an array or structure field access), or an ASM-level IR (where the address calculation might be broken up over several different instructions).

LLVM is pretty low-level. It's a bit lower-level than C and has a very simple type system. It has no idea about unique pointers versus references, has no concept of borrowing, etc. I bet you could encode the necessary information for performing say borrow-checking into LLVM IR, but working with that would not necessarily be pleasant.

A good example of this is ARC optimization in Swift, which gets rid of unnecessary reference counting operations. That optimization operates on SIL, which has special instructions for reference counting. You could represent those instructions as magic intrinsics in LLVM IR, but you have no way of imposing any structural restrictions on how those intrinsics are used. Moreover, any pass which operated on LLVM IR to optimize uses of those intrinsics, would have to make deep assumptions about the semantics of those operations. Those assumptions, being Swift-specific, would mean the pass could not be used by other languages, which removes a lot of the benefit of making it an LLVM pass in the first place.

Re:Introducing MIR by DannyBee on Wednesday April 27, 2016 @02:30PM (#11583198)
For starters, LLVM has a very simple type system. very simple. So pretty much any optimization that relies on type knowledge, unless it's a simple optimization (IE can be expressed as an attribute on lowered types, ...) needs are a higher level IR. Things are also legal in LLVM IR that are not legal in any of the languages it supports, for example, getelementptr can be used with negative indices, etc.

Some language rules and optimizations are easy to express in LLVM IR, but there are plenty that are not.

You could add metadata, but you'd probably have to extend how metadata works to support a bunch of things, and even then, the community would want metadata designs that multiple language frontends can use, not just yours.

Re:Introducing MIR by pklausler on Wednesday April 27, 2016 @02:40PM (#11583299)
> Things are also legal in LLVM IR that are not legal in any of the languages it supports, for example, getelementptr can be used with negative indices, etc.

Not sure what you're talking about here; what's wrong with negative indices in C?

Re:Introducing MIR by DannyBee on Wednesday April 27, 2016 @05:02PM (#11584526)
First, remember that getelementptr != array indices.

Second, remember that even in C, you can't actually dereference things outside of the bounds of an object, even if you can form addresses to it.

In any case, the point was more than something like

  struct foo C;

  char *foo = &C
  foo -= 7;
  char whee = *foo;
Is legal in llvm, but not in say, C++ (and in fact, in most languages it's not legal because it's not aligned properly)
Re:Introducing MIR by pklausler on Wednesday April 27, 2016 @05:36PM (#11584766)
"char" in C/C++ can't be misaligned.
Re:Introducing MIR by DannyBee on Wednesday April 27, 2016 @09:23PM (#11585978)
I didn't say it can, i said "in fact, in most languages" (IE not C/C++). In C/C++, it's illegal for other reasons.
Re:Introducing MIR by kibwen on Wednesday April 27, 2016 @02:53PM (#11583446)
I Am Not A Language Lawyer, but there's no way that negative indices aren't UB in C.
Re:Introducing MIR by pklausler on Wednesday April 27, 2016 @02:58PM (#11583485)

  int a[100];
  int *p = &a[50];
  a[0] = 666;
  printf("%d\n", p[-50]);
Remember that x[y] in C just means *((x)+(y)). You can offset pointers with positive and negative offsets so long as the resulting pointer remains within the bounds of an object.

(EDIT: formatting so HN doesn't misinterpret code point U+2A.)

Re:Introducing MIR by munificent on Wednesday April 27, 2016 @04:28PM (#11584241)
I actually use negative indices in real code[1].

If you implement a stack using an array and you track the top of stack by a pointer just past the last element, then you can index negatively into that pointer to access items on the stack:

    // Create an empty stack.
    int stack[100];
    int* top = &stack;

    // Push a couple of values.
    *top++ = 123;
    *top++ = 456;

    // Peek the values.
    printf("%d\n", top[-1]); // 456.
    printf("%d\n", top[-2]); // 123.
You could make the pointer arithmetic more explicit like this:

    printf("%d\n", *(top - 1)); // 456.
But I think that's needlessly verbose.

[1]: https://github.com/munificent/wren/blob/master/src/vm/wren_v...

Re:Introducing MIR by jeffdavis on Thursday April 28, 2016 @03:55AM (#11587136)
For something like that, I would use the explicit pointer arithmetic. The array syntax implies (to me) "I am doing the normal thing with this normal array".
Re:Introducing MIR by kibwen on Wednesday April 27, 2016 @04:22PM (#11584200)
I'm aware that index notation in C is just sugar for pointer arithmetic, but I'm under the impression that the interpretation of "within the bounds of an object" is less liberal than that demonstrated in your code example. In particular it's not clear to me that a pointer derived from an offset into an existing allocation does not constitute a new object, with its own bounds. Maybe I'm just spoiled by languages with proper slices...
Re:Introducing MIR by pklausler on Wednesday April 27, 2016 @05:19PM (#11584665)
Your impression unfortunately turns out to not be the case. You can move pointers forward and backward within an array using pointer +/- integer arithmetic or (equivalently) the prefix and postfix ++/-- operators, and it's well-defined so long as you don't back up over the beginning of the array or go more than one element past the end.

See section 6.5.6, paragraph 8, of the ISO C standard, if you want the legalese. But this is pretty basic C that dates back to the beginning of the language.

Re:Introducing MIR by Gankro on Wednesday April 27, 2016 @07:12PM (#11585372)
This working is entirely necessary for C++-style handle-iterators to work. Rust's slice iterators are implemented in the exact same fashion precisely because C/C++ does this a lot and LLVM is trained to "get" it.