[llvm] [TargetLowering] Speculative fix for a non-determinism issue between different compilers. (PR #190219)

[Craig Topper via llvm-commits]

topperc wrote:

> We have a lot of nested getNode() calls, I'm surprised this is an actual issue. Could there be a hasOneUse check someplace or something todo with constant folding?

I've dumped the debug output with both operand orders. Because of the squaring, we create multiple multiply nodes with identical operands in opposite order. Because of the different node creation order they get visited by the next DAG combine in a different order. This causes the commuting CSE code at the bottom of `DAGCombiner::combine` to pick a different node as the canonical one. This results in the machine IR having the same instructions but different operand order. This is -O0 so operand order effects how the fast register allocator behaves.

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