Various improvements to MIR and LLVM IR Construction #32980

Primarily affects the MIR construction, which indirectly improves LLVM IR generation, but some LLVM IR changes have been made too. * Handle "statement expressions" more intelligently. These are expressions that always evaluate to `()`. Previously a temporary would be generated as a destination to translate into, which is unnecessary. This affects assignment, augmented assignment, `return`, `break` and `continue`. * Avoid inserting drops for non-drop types in more places. Scheduled drops were already skipped for types that we knew wouldn't need dropping at construction time. However manually-inserted drops like those for `x` in `x = y;` were still generated. `build_drop` now takes a type parameter like its `schedule_drop` counterpart and checks to see if the type needs dropping. * Avoid generating an extra temporary for an assignment where the types involved don't need dropping. Previously an expression like `a = b + 1;` would result in a temporary for `b + 1`. This is so the RHS can be evaluated, then the LHS evaluated and dropped and have everything work correctly. However, this isn't necessary if the `LHS` doesn't need a drop, as we can just overwrite the existing value. * Improves lvalue analysis to allow treating an `Rvalue::Use` as an operand in certain conditions. The reason for it never being an operand is so it can be zeroed/drop-filled, but this is only true for types that need dropping. The first two changes result in significantly fewer MIR blocks being generated, as previously almost every statement would end up generating a new block due to the drop of the `()` temporary being generated.

Moves `stmt_expr` into its own module, `expr::stmt`.

The drop glue for `i8` is no longer generated as a trans item

In code like `let x = y = z;`, `y = z` goes through `as_rvalue`, which didn't handle it. Now it translates the assignment and produces `()` directly.

`new_operand` now checks the type it's given and either creates the nil value itself, or produces an empty operand.

I'm not sure what the signficance of `drop-glue i8` is, nor why one of the tests had it appear while the others had it disappear. Either way it doesn't seem like the presence or absense of it is the focus of the tests.

Use either getelementptr or extractvalue depending on whether or not the tuple is immediate or not.

LLVM's assertion doesn't provide much insight as to what the problem was. We were already checking `call` instructions ourselves, so this brings the checks from there to `invoke`. Both the `invoke` and `call` checking is controlled by `debug_assertions`.

The logic for checking `call` and `invoke` instructions was duplicated between them, so factor it out to a helper method.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Various improvements to MIR and LLVM IR Construction #32980

Various improvements to MIR and LLVM IR Construction #32980

Commits on Apr 28, 2016