Missed optimization of constant folding when using 'trunc nuw i64 %v to i1'

[GINN-Imp]

The following reduced IR is derived from https://github.com/rust-lang/regex/blob/1a069b9232c607b34c4937122361aa075ef573fa/regex-automata/src/util/pool.rs#L542.

Godbolt: https://godbolt.org/z/KebcfWbE8 (contains the source code before manual reduce)
alive2 proof: https://alive2.llvm.org/ce/z/XPqJVm

Missed optimization: store i64 %v, ptr %p, align 8 --> store i64 0, ptr %p, align 8

While Alive2 confirms that this transformation is correct, I’m having some difficulty fully understanding the semantic justification—particularly with respect to how trunc nuw i64 %v to i1 constrains %v. I would greatly appreciate any clarification on why this optimization is considered valid.

define i64 @src(ptr %p, i64 %v) {
  %trunc = trunc nuw i64 %v to i1
  br i1 %trunc, label %common.ret, label %3

common.ret:                                       ; preds = %1, %3
  ret i64 0

3:                                                ; preds = %1
  store i64 %v, ptr %p, align 8
  br label %common.ret
}

expected:

define i64 @tgt(ptr %p, i64 %v) {
  %trunc = trunc nuw i64 %v to i1
  br i1 %trunc, label %common.ret, label %3

common.ret:                                       ; preds = %1, %3
  ret i64 0

3:                                                ; preds = %1
  store i64 0, ptr %p, align 8
  br label %common.ret
}

[yashnator]

Hi @GINN-Imp, I think the constraint emerges from truncating %v to i1. For %v > 1, we get a poison value which is then used in the branch instruction that triggers UB. So we are left with %v = 0 or 1, which leads to storing 0 to %p in 3.

Maybe we can optimise this for truncations with nuw?

I'm not entirely sure if this reasoning is complete, so I wanted to check whether this direction makes sense before proceeding. Any pointers or confirmation would be really helpful.

[GINN-Imp]

Hi @GINN-Imp, I think the constraint emerges from truncating %v to i1. For %v > 1, we get a poison value which is then used in the branch instruction that triggers UB. So we are left with %v = 0 or 1, which leads to storing 0 to %p in 3.

Maybe we can optimise this for truncations with nuw?

I'm not entirely sure if this reasoning is complete, so I wanted to check whether this direction makes sense before proceeding. Any pointers or confirmation would be really helpful.

Thanks for the explanation! That does sound plausible, though unfortunately I’m not entirely sure either.