[PATCH] D55120: [MemCpyOpt] memset->memcpy forwarding with undef tail

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 6 11:13:28 PST 2018


efriedma added inline comments.


================
Comment at: lib/Analysis/MemoryDependenceAnalysis.cpp:173
+      Loc = MemoryLocation::getForArgument(II, 0, TLI);
+      return ModRefInfo::Mod;
     default:
----------------
nikic wrote:
> efriedma wrote:
> > This probably makes sense, but it looks like it'll impact other transforms; would it be possible to test separately?  Or does it actually not have any impact on other transforms for some reason?
> > 
> > Looks fine otherwise.
> It seems that it indeed does not impact other transforms, at least not in any way that I can see. The main consumer of `GetLocation()` is `getDependency()`, for which:
> 
>  * GVN only deals with loads.
>  * DSE has it's own mechanism for determining location.
>  * MemCpyOpt does not call getDependency on memsets (prior to this change).
> 
> The other consumer is `getCallSiteDependencyFrom()`, where previously memset would have been treated as a normal call-site. However in both cases (known location or call-site) the result will ultimately be determinded by AA.
> 
> ---
> 
> What I'm unsure about is whether this is correct wrt handling of volatile. I see in the code above that an ordered (and non-monotonic) StoreInst will return ModRef with empty location. Maybe memset needs the same treatment for volatile?
We don't really use volatile memsets anywhere important, but yes, probably best to be conservative and treat them as ModRef.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D55120





More information about the llvm-commits mailing list