[llvm] [IPSCCP] Do not attempt `tryToReplaceWithConstant` if may break invariants (PR #102820)

[Shoaib Meenai via llvm-commits]

smeenai wrote:

> > > > It's even more obvious when you consider that the returned constant may just be a constant integer/float rather than a global. That can open up all kinds of optimizations, and is also something where rematerialization is more likely to be profitable.
> > > 
> > > 
> > > Makes sense. Could reverting the constant replacement be an option, once DCE and friends have used SCCP results and have run, and we know materializing the constant turned out to be not profitable (as it is the case in #102791)? So, possibly somewhere in SelectionDAG?
> > 
> > 
> > At least in principle, yes, we could do that. It may be easier to handle in CGP rather than SDAG, esp. for cross-block cases.
> 
> Right, cleaning up the IR for this in CGP may be more amenable – thanks for the suggestion!

For my own understanding (as someone who's barely worked on the middle-end), how would this work? I looked through CodeGenPrepare, and it seems to be mostly peephole optimizations. For the problem in #102791, I guess what we want is to recognize that:
1. We're calling a function and then operating on a value that's the same as the return value of the function (but we're not using the return value directly).
2. It's more expensive to recompute that value instead of using the function's return value. When we've reached CodeGenPrepare, this should always be true when the use immediately follows the function call (at least in all the cases I can think of). It's less obvious when you'd need to use an extra register (or stack slot) to hold on to the return value vs. recomputing it, so maybe limiting the transformation to not operate beyond a call would be a good starting point?

How would we do part 1? Would we have to perform the same analysis SCCP did in the first place to determine this, or does SCCP do some bookkeeping on its replacements that we could use to undo them later?

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