[llvm] [DAGCombiner] Optimize more vector element extractions. (PR #80520)

[Harald van Dijk via llvm-commits]

================
@@ -190,10 +190,6 @@ define <2 x half> @v_test_canonicalize_build_vector_v2f16(half %lo, half %hi) #1
 ; CI-LABEL: v_test_canonicalize_build_vector_v2f16:
 ; CI:       ; %bb.0:
 ; CI-NEXT:    s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
-; CI-NEXT:    v_cvt_f16_f32_e32 v0, v0
-; CI-NEXT:    v_cvt_f16_f32_e32 v1, v1
-; CI-NEXT:    v_cvt_f32_f16_e32 v0, v0
-; CI-NEXT:    v_cvt_f32_f16_e32 v1, v1
 ; CI-NEXT:    s_setpc_b64 s[30:31]
----------------
hvdijk wrote:

Ah. DAGCombiner's [`getCopyFromParts`](https://llvm.org/doxygen/SelectionDAGBuilder_8cpp.html#acb8cf9e50c3979193572ea36f327d0a4) creates a `FP_ROUND` with a `TRUNC` value of `1`, [documented as "TRUNC is a flag, which is always an integer that is zero or one. If TRUNC is 0, this is a normal rounding, if it is 1, this FP_ROUND is known to not change the value of Y. The TRUNC = 1 case is used in cases where we know that the value will not be modified by the node, because Y is not using any of the extra precision of source type."](https://llvm.org/doxygen/namespacellvm_1_1ISD.html#a22ea9cec080dd5f4f47ba234c2f59110adaf9a3cb5c2ef5eb713bd6bf4ae23aeb) But this looks wrong: even if Y is known not to be using any of the extra precision of the source type, `FP_ROUND` may *still* change the value by turning a sNaN into a qNaN.

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