[llvm] [DAGCombiner] Avoid illegal scalar nodes in estimate refinement (PR #219394)

[via llvm-commits]

MattPD wrote:

Related scope and prior work:

This patch changes only the refinement constants created by `BuildDivEstimate` and `buildSqrtNRTwoConst`.

`buildSqrtNROneConst` remains unchanged because no in-tree target reaches it with a legal fixed-length vector whose scalar element action is `TypeSoftenFloat`.

Three other paths still reach the missing `SoftenFloatOperand` `BUILD_VECTOR` case: vector constants originating in IR, vector constants that other producers build from scalar operands, and the reciprocal numerator synthesized by `combineRepeatedFPDivisors`. Each requires a separate fix.

Feel free to let me know whether I should file a separate follow-up issue for each of these three paths.

`TargetLowering::getSqrtInputTest` and `getSqrtResultForDenormInput` also remain unchanged. `X86TargetLowering::getSqrtEstimate` requires `Subtarget.hasSSE2()` for its `MVT::v4f32` case when `Reciprocal` is false. The SSE2 subtarget configuration makes scalar `f32` legal.

Issue https://github.com/llvm/llvm-project/issues/217801 tracks scalar estimate-result legality.

Issue https://github.com/llvm/llvm-project/issues/38086 documented the same missing `SoftenFloatOperand` `BUILD_VECTOR` case in different producers of X86 memory operations. Commit https://github.com/llvm/llvm-project/commit/925b64be64d7da078c70d621b787015c8073dcca changed those producers without implementing estimate-refinement constant materialization.


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