[TTI][RISCV] Unconditionally break critical edges to sink ADDI (#108889)

This looks like a rather weird change, so let me explain why this isn't
as unreasonable as it looks. Let's start with the pr

[TTI][RISCV] Unconditionally break critical edges to sink ADDI (#108889)

This looks like a rather weird change, so let me explain why this isn't
as unreasonable as it looks. Let's start with the problem it's solving.

```
define signext i32 @overlap_live_ranges(ptr %arg, i32 signext %arg1) { bb:
%i = icmp eq i32 %arg1, 1
br i1 %i, label %bb2, label %bb5

bb2: ; preds = %bb
%i3 = getelementptr inbounds nuw i8, ptr %arg, i64 4
%i4 = load i32, ptr %i3, align 4
br label %bb5

bb5: ; preds = %bb2, %bb
%i6 = phi i32 [ %i4, %bb2 ], [ 13, %bb ]
ret i32 %i6
}
```

Right now, we codegen this as:

```
li a3, 1
li a2, 13
bne a1, a3, .LBB0_2
lw a2, 4(a0)
.LBB0_2:
mv a0, a2
ret
```

In this example, we have two values which must be assigned to a0 per the
ABI (%arg, and the return value). SelectionDAG ensures that all values
used in a successor phi are defined before exit the predecessor block.
This creates an ADDI to materialize the immediate in the entry block.

Currently, this ADDI is not sunk into the tail block because we'd have
to split a critical edges to do so. Note that if our immediate was
anything large enough to require two instructions we *would* split this
critical edge.

Looking at other targets, we notice that they don't seem to have this
problem. They perform the sinking, and tail duplication that we don't.
Why? Well, it turns out for AArch64 that this is entirely an accident of
the existance of the gpr32all register class. The immediate is
materialized into the gpr32 class, and then copied into the gpr32all
register class. The existance of that copy puts us right back into the
two instruction case noted above.

This change essentially just bypasses this emergent behavior aspect of
the aarch64 behavior, and implements the same "always sink immediates"
behavior for RISCV as well.

show more ...

[RISCV] Add coverage for immediate sinking in switch vs branch cases

This come up in the context of pr 108889. We always end up sinking
the value in the phi if we dispatched via a switch, but not i

[RISCV] Add coverage for immediate sinking in switch vs branch cases

This come up in the context of pr 108889. We always end up sinking
the value in the phi if we dispatched via a switch, but not if we'd
dispatched via a branch. This is purely an artifact of current
lowering.

show more ...

[RISCV] Add a testcase for an unprofitable machine-sink issue

This corresponds to an upcoming change which will fully explain
why this is a machine-sink issue.

[MachineSink] Fix missing sinks along critical edges (#97618)

4e0bd3f improved early MachineLICM's capabilities to hoist COPY from
physical registers out of a loop. However, it accidentally broke o

[MachineSink] Fix missing sinks along critical edges (#97618)

4e0bd3f improved early MachineLICM's capabilities to hoist COPY from
physical registers out of a loop. However, it accidentally broke one of
MachineSink's preconditions on sinking cheap instructions (in this case,
COPY) which considered those instructions being profitable to sink only
when there are at least two of them in the same def-use chain in the
same basic block. So if early MachineLICM hoisted one of them out,
MachineSink no longer sink rest of the cheap instructions. This results
in redundant load immediate instructions from the motivating example
we've seen on RISC-V.

This patch fixes this by teaching MachineSink that if there is more than
one demand to sink a register into the same block from different
critical edges, it should be considered profitable as it increases the
CSE opportunities.
This change also improves two of the AArch64's cases.

show more ...

[test][MachineSink][RISCV] Pre-commit test for #97618