Optimization for types implementing drop seems broken on LLVM 19 about rust HOT 3 OPEN

FYI @jwong101

from rust.

@rustbot claim

from rust.

After taking a look at this, the problem seems to be that GVN isn't propagating the pointer equalities in the following IR after this PR:

define void @src(ptr noundef %buf, ptr noundef %start, ptr noundef %end) {
bb2:
  %iter.exhausted = icmp eq ptr %end, %start
  br i1 %iter.exhausted, label %bb5, label %bb3

bb3:                                       ; preds = %bb2
  %iter.empty.loop = icmp eq ptr %end, %buf
  br i1 %iter.empty.loop, label %bb5, label %exit

bb5:                                              ; preds = %bb2, %bb3
  %self.end = phi ptr [ %buf, %bb3 ], [ %start, %bb2 ]
  ;%self.end = phi ptr [ %end %bb3 ], [ %end %bb2 ] <- gvn used to propogate this
  %_710.i.i = icmp eq ptr %end, %self.end
  br i1 %_710.i.i, label %exit, label %bb6

bb6:                                          ; preds = %bb5
  %inner.cap = load i64, ptr %self.end, align 8, !noundef !0
  call void @effect(i64 %inner.cap)
  br label %exit

exit: ; preds = %bb3, %bb5, %bb6
  ret void
}


define void @tgt(ptr noundef %buf, ptr noundef %start, ptr noundef %end) {
  ret void
}

Alive Proof

Before, GVN would blindly propagate %end to each operand of %self.end. Just doing that is incorrect, since there's a load of %self.end, which might not have the same provenance as the replaced pointer.

However, it should be sound to propagate pointer equality to just comparisons, which the PR does when the only uses are icmp or ptrtoint instructions or phi and select instructions that feed into them.

Unfortunately, this doesn't help in our case, since the phi node is also used by a load. My naive idea would be to either create duplicate phi nodes that are only used by ptrtoint or icmp, so we can propagate equality there or store pointer equality information about the phi node in some side table and replace only icmp and ptrtoint uses if all of the phi node operands turn out to be equivalent.

There's probably a better way, as I'm not that familiar with LLVM's GVNpass. Is there another approach I could take for solving the above problem; should I be looking at another pass?

from rust.