[llvm] [DAG] SimplifyMultipleUseDemandedBits - simplify ISD::SCALAR_TO_VECTOR to ISD::POISON if we don't demand 0th element (PR #225530)

[Cyrus Ding via llvm-commits]

dingcyrus wrote:

Thanks for the follow-up, Simon — and for picking up the fold that I only added to the DAGCombiner helpers during the #217185 review.

The new case looks right to me: with `DemandedElts[0]` clear, every demanded lane of a `SCALAR_TO_VECTOR` is one of the documented-poison upper elements, so replacing the node with `getPOISON(VT)` for this use is sound, and it keeps `SimplifyMultipleUseDemandedBits` consistent with the `!DemandedElts[0] -> POISON` branches in `SimplifyDemandedBits`/`SimplifyDemandedVectorElts`, as well as with the poison semantics #217185 enforced in `canCreateUndefOrPoison`/`isGuaranteedNotToBeUndefOrPoison`. The `!isScalableVector()` guard matches the BITCAST case above (and for scalable vectors the demanded-elts mask is conservative, so the fold wouldn't fire anyway).

Cross-checked against my still-open #224213 (AArch64 `freeze(extload)` scalar_to_vector/bitconvert patterns, #224181): no interaction — those shapes demand element 0, so the new fold doesn't apply, and the ISel-level pattern gap is independent of this DAG fold. #224213 remains needed as-is, and the plan to drop the promoted-load guard on the `SimplifyDemandedVectorElts` freeze sink once it lands is unaffected.

LGTM from my side — please count this as the #217185 author's endorsement of the semantics.


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