[gcc/devel/rust/master] Merge #1367

[gcc/devel/rust/master] Merge #1367

[Thomas Schwinge]

https://gcc.gnu.org/g:b1c9ac14a06a2c0dd4acb8758f3c88c2c610a31e

commit b1c9ac14a06a2c0dd4acb8758f3c88c2c610a31e
Merge: a5c82a1d2b4 b7c4aa942fa
Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
Date:   Thu Jul 7 20:00:19 2022 +0000

    Merge #1367
    
    1367: Initial support for matches on tuples r=dafaust a=dafaust
    
    Initial work on supporting more complex match expressions, starting with tuples. It's proven to be quite a bit more complicated than I originally expected. Still this implementation is very naive, probably very poor performance, and skips all the nuanced stuff like bindings in patterns and pattern guards.
    
    Overview
    The general idea is that we lower `MatchExpr`s to `SWITCH_EXPR` trees, but a switch can only operate on one value at a time. When scrutinizing a tuple, we can't build a switch that checks all the elements at once. So instead, just before lowering to trees, we construct a new set of nested match expressions which tests the tuple one element at a time, and is (hopefully) semantically identical to the original match. These new nested matches are simplified, so that each one tests only one thing and therefore *can* lower directly to a `SWITCH_EXPR`.
    
    To see an example, this
    ```text
    match (tupA, tupB, tupC) {
      (a1, b1, c1) => { blk1 }
      (a2, b2, c2) => { blk2 }
      (a1, b3, c3) => { blk3 }
      ...
      _ => { blk4 }
    }
    ```
    after one step becomes
    ```text
    match tupA {
      a1 => {
        match (tupB, tupC) {
          (b1, c1) => { blk1 }
          (b3, c3) => { blk3 }
          ...
          _ => { blk4 }
        }
      a2 => {
        match (tupB, tupC) {
          (b2, c2) => { blk2 }
          ...
          _ => { blk4 }
        }
      }
      _ => { blk4 }
    }
    ```
    Repeat until all matches are fully simplified, then compile it all into trees.
    
    Now, we might end up with a lot of duplicated basic blocks here as a result, but the optimization in GENERIC and GIMPLE (further on in gcc) is very good and knows how to take care of that for us.
    
    This approach seems somewhat similar to how rustc lowers HIR to MIR, which is hopefully a good sign :)
    
    Addresses: #1081
    
    Co-authored-by: David Faust <david.faust@oracle.com>

Diff:

 gcc/rust/backend/rust-compile-expr.cc              | 472 +++++++++++++++++++--
 gcc/rust/hir/tree/rust-hir.h                       |   6 +
 gcc/testsuite/rust/execute/torture/match_tuple1.rs |  41 ++
 3 files changed, 494 insertions(+), 25 deletions(-)