[llvm] [DRAFT][RegisterCoalescer] Enable non-trivial rematerialization (PR #160153)

[Luke Lau via llvm-commits]

https://github.com/lukel97 commented:

In my head I had understood non-trivial rematerialization as rematerialization of an instruction with a virtual register use **that needs its live range extended**, mostly based off of this existing comment:

```
    // Rematting an instruction with
    // virtual register uses would length the live ranges of the uses, which
    // is not necessarily a good idea, certainly not "trivial".
```

But I think I agree now that a better definition is trivial = guaranteed to always be remateralizable, non-trivial = may succeed if the uses are live at the point of rematerialization.

I would prefer the alternative approach you suggested:

> An alternate API approach would be to update TTI to always return the non-trivial result, and then copy the MachineLICM approach of explicitly checking for non-triviality afterwards.

Where `isTriviallyReMaterializable` would check for virtual registers. We'd then go through and replace existing uses of `isTriviallyReMaterializable`  in the first group of users you identified (where they check for use availability) with `isReMaterializable`

In theory and with #159180, I would hope that there would never be any downside to rematerializing an instruction whose uses are live at the point of rematerialization, and the test runs in #159211 didn't show any indication of the contrary.

So in the interest of avoiding backend fragmentation, I think we should be optimistic here and assume that this is beneficial for all targets. If after this lands we get issues reported on specific targets, we can go back and revisit this to be opt-in

https://github.com/llvm/llvm-project/pull/160153