Similar optimization in Transforms/InstCombine/shuffle_select.ll:

define <4 x i32> @add_undef_mask_elt(<4 x i32> %v) {
  %b = add <4 x i32> %v, { 11, 12, 13, 14 }
  %s = shufflevector <4 x i32> %b, <4 x i32> %v, <4 x i32> { 0, 5, undef, 7 }
  ret <4 x i32> %s
}
=>
define <4 x i32> @add_undef_mask_elt(<4 x i32> %v) {
  %s = add <4 x i32> %v, { 11, 0, undef, 0 }
  ret <4 x i32> %s
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source

Example:
<4 x i32> %v = < poison, poison, poison, poison >

Source:
<4 x i32> %b = < poison, poison, poison, poison >
<4 x i32> %s = < poison, poison, undef, poison >

Target:
<4 x i32> %s = < poison, poison, poison, poison >
Source value: < poison, poison, undef, poison >
Target value: < poison, poison, poison, poison >

This is with the semantics of LangRef, where an undef mask stops propagation of poison.

This seems unfortunate. Can you please remind me why we choose these semantics? It seems to me that (add undef, poison) should be poison, not undef, no?

This is with the semantics of LangRef, where an undef mask stops propagation of poison.

This seems unfortunate. Can you please remind me why we choose these
semantics? It seems to me that (add undef, poison) should be poison, not
undef, no?

See the discussion here: #43303

Short version, this semantics is needed if we want to support things introduction of broadcast:

%t = insertelement <4 x float> undef, float %arg, i32 1
%t4 = insertelement <4 x float> %t, float %arg, i32 1
%t5 = insertelement <4 x float> %t4, float %arg, i32 2
%t6 = insertelement <4 x float> %t5, float %arg, i32 3
ret <4 x float> %t6
=>
%t = insertelement <4 x float> undef, float %arg, i32 0
%t2 = shufflevector <4 x float> %t, <4 x float> undef, <4 x i32> <i32 undef, i32 0, i32 0, i32 0>
ret <4 x float> %t2

IMHO, the correct fix is to introduce a poison value and use that to initialize vectors. Also, a poison mask would give poison, so no more of these problems of choosing "undef or poison -> undef". Using shufflevector to stop poison isn't ideal, since then we can't remove it.
BTW, I've shown in #​43958 that these bugs are exploitable for end-to-end miscompilations.

This is with the semantics of LangRef, where an undef mask stops propagation of poison.

This seems unfortunate. Can you please remind me why we choose these
semantics? It seems to me that (add undef, poison) should be poison, not
undef, no?

See the discussion here: #43303

Short version, this semantics is needed if we want to support things
introduction of broadcast:

%t = insertelement <4 x float> undef, float %arg, i32 1
%t4 = insertelement <4 x float> %t, float %arg, i32 1
%t5 = insertelement <4 x float> %t4, float %arg, i32 2
%t6 = insertelement <4 x float> %t5, float %arg, i32 3
ret <4 x float> %t6
=>
%t = insertelement <4 x float> undef, float %arg, i32 0
%t2 = shufflevector <4 x float> %t, <4 x float> undef, <4 x i32> <i32
undef, i32 0, i32 0, i32 0>
ret <4 x float> %t2

IMHO, the correct fix is to introduce a poison value and use that to
initialize vectors. Also, a poison mask would give poison, so no more of
these problems of choosing "undef or poison -> undef".

That makes sense to me. I expect that in many cases where we use an 'undef' constant, a poison constant would be a better fit. It's the "I need to put a value here, but the program shouldn't ever actually depend on it" value, and at least informally, that's how undef has often been used (as opposed to "the program can depend on it, and it's arbitrary, but that won't matter to the user" undef semantics).

Using shufflevector
to stop poison isn't ideal, since then we can't remove it.
BTW, I've shown in #​43958 that these bugs are exploitable for end-to-end
miscompilations.

It's the "I need to put a value here, but the program shouldn't ever actually depend on it" value, and at least informally, that's how undef has often been used (as opposed to "the program can depend on it, and it's arbitrary, but that won't matter to the user" undef semantics).

This is a nice succinct explanation of the difference between the two, that seems to be missing from the langref's explanation of the constants.

mentioned in issue #47292

Juneyoung's patches so they don't get lost:
https://reviews.llvm.org/D93818
https://reviews.llvm.org/D103874

FWIW, I've switched the semantics of shufflevector in Alive2 to yield poison elements when idx is OOB.
This fixed quite a few tests, but a few regressed as well:

• Transforms/InstCombine/broadcast.ll
• Transforms/InstCombine/insert-const-shuf.ll
• Transforms/InstCombine/sub-of-negatible.ll
• Transforms/SLPVectorizer/X86/blending-shuffle-inseltpoison.ll
• Transforms/SLPVectorizer/X86/blending-shuffle.ll
• Transforms/SLPVectorizer/X86/crash_lencod.ll
• Transforms/SLPVectorizer/X86/hadd.ll
• Transforms/SLPVectorizer/X86/insert-element-build-vector-const-undef.ll
• Transforms/SLPVectorizer/X86/sitofp.ll
• Transforms/VectorCombine/X86/load.ll

I've inspected all of them. They are all related with mixed insertelement starting with undef vectors. I suggest we restrict these optimizations to just poison vectors as undef vectors should be very rare nowadays.