[PATCH] D38374: [memcpyopt] Memcpy-memcpy dependence isn't detected across basic blocks
Dan Gohman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Nov 30 14:10:56 PST 2017
sunfish marked 3 inline comments as done.
sunfish added inline comments.
================
Comment at: lib/Transforms/Scalar/MemCpyOptimizer.cpp:1274
if (MemSetInst *MDep = dyn_cast<MemSetInst>(SrcDepInfo.getInst()))
if (performMemCpyToMemSetOptzn(M, MDep)) {
MD->removeInstruction(M);
----------------
sanjoy wrote:
> sunfish wrote:
> > sanjoy wrote:
> > > IIUC, this may try to create illegal IR (def not dominating use) if it finds the non-local memset via a backedge since it tries to create a memset before the memcpy using the memset's value operand, which may not dominate the memcpy with your change.
> > If the memset doesn't dominate the memcpy, the non-local dependence results reflect this. For example, in
> > ```
> > for (...) {
> > memcpy(out, buffer, size);
> > memset(buffer, 0, size);
> > }
> > ```
> > the memcpy depends on the memset around the backend, but memdep reports two dependencies: the memcpy on the backedge, but also whatever there is on the loop entry edge, so the code in this patch requiring a single dependency doesn't accept it.
> Ok, can you then add an assert that `SrcDepInfo.getInst()` dominates `M` (specifically in the cases where you computed it from a singular non-local dependency)?
Makes sense. I've now added the asserts.
Repository:
rL LLVM
https://reviews.llvm.org/D38374
More information about the llvm-commits
mailing list