[PATCH] D140697: [MemCpyOpt] Merge succeeding undefs while attempting a `memset`

[Jamie Hill-Daniel via Phabricator via llvm-commits]

clubby789 added a comment.

In D140697#4017797 <https://reviews.llvm.org/D140697#4017797>, @nikic wrote:

> 1. Profitability: As implemented, I believe this will also transform some non-profitable cases, e.g. imagine a store 0, followed by one hundred store undef, followed by store 0. We'd rather make those two stores than one long memset. This needs some kind of profitability heuristic.

I've updated the `isProfitable` function to take into account the number of *non undef* stores rather than stores overall.

> 2. Phase ordering: InstCombine will remove store undef, and it runs before MemCpyOpt. So MemCpyOpt will actually never see this kind of IR (except in degenerate cases) and this change will not make any difference in end-to-end compilation. What one could do here is to allow "holes" in the memset range if the memory is known to be uninitialized beforehand, though that wouldn't apply in your example.

The motivation for this is https://github.com/rust-lang/rust/issues/104290 - experimentally adding `MemCpyOpt` between an early SROA and InstCombine pass does indeed fix this case, but causes a regression in `instcombine-sroa-inttoptr.ll`. I'm also not sure if it's appropriate to run this pass so early on.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140697/new/

https://reviews.llvm.org/D140697