Not sure who to assign for review, so I added the SelectionDAG code owner.

Rebase over APInt patch, implement new undef folds with zero result.

Rebase on separate APInt patch.

Is it perhaps "better" to fold sadd_sat(X, undef) -> 0 And uadd_sat(X, undef) -> MaxValue if we want to get rid of undef here? That way we get rid of the X operand as well.

Simplify sat(X - undef) -> X for symmetry with the add simplification.

Add simplify for X + undef -> X.

Rebase patch to current master.

I've added an implementation for saturating subs in D54274. Please tell me if I should combine the changes into this one instead.

Improve control-flow in APInt implementation, fix typo in comment.

Address style comments, move trivial transforms to InstructionSimplify, add APInt unit test, move code for overflow information based checks outside the condition for a constant operand (duh).

// X + undef -> undef

// undef + X -> undef
if (match(Op1, m_Undef()) || match(Op0, m_Undef()))
  return UndefValue::get(ReturnType);

Ping

As I don't have commit rights, could you please commit D53262, D53271 and this revision?

Added comment about thunk/alias checks for the weak-weak case. Also renamed the function H to NewF, because I think this makes it slightly more obvious what is going on in that case.

@whitequark I don't have commit access, could I ask you to land this patch?

Remove some trailing semicolons in the test file ... hard to break that habit.

Rust currently generates additional code for u128 to f32 casts to work around this problem (see https://github.com/rust-lang/rust/blob/c131bdcaff68d35f96e954baac4340206779335f/src/librustc_codegen_llvm/mir/rvalue.rs#L795). Making this defined would allow directly using uitofp, so this would be a welcome change.

For reference, another bug relating to NewGVN + Simplify is https://bugs.llvm.org/show_bug.cgi?id=34093. In that case it's not a matter of metadata, but an equivalence that was established based on predicateinfo is assumed to hold prior to the corresponding ssa.copy, resulting in incorrect simplification.

@fhahn It's probably not feasible to remove metadata or explicitly pass merged metadata as the relevant metadata may be somewhere further up the chain. E.g. we might not be looking at ICmp(Load, null) but at something like ICmp(BitCast(GEP(Load)), null), which will probably be subject to the same issues, as these checks are recursive.

This is going to affect more than only nonnull metadata. For example the same issue can also be reproduced using range metadata:

I don't have commit access, could someone please commit this patch?

Address nit.

Sorry, I misunderstood your previous comment and thought you were referring to the return type. I've added two variants to the test now, one where a non-null argument is used and it can be merged and one where it can't be merged.

Updated test to test both different pointer types as inline asm argument types and return types.