Follow-up patch to introducing Must in ModRefInfo, set the Must flag for a larger subset of calls.
Must is set if MustAlias and NoAlias is found (no May or Partial alias).
Details
- Reviewers
sanjoy
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 13952 Build 13952: arc lint + arc unit
Event Timeline
lib/Analysis/AliasAnalysis.cpp | ||
---|---|---|
193 | Is this bit changing behavior? Both before and after we look at IsMustAlias only when DoesAlias is true, and your change only possibly changes the value of IsMustAlias in the cases where DoesAlias is false. |
lib/Analysis/AliasAnalysis.cpp | ||
---|---|---|
193 | Let me try to reason this out loud. if (ArgAlias != MustAlias) IsMustAlias = false Before: IsMustAlias is set to false when NoAlias is found. So for a list of arguments (a=MustAlias, b=NoAlias), DoesAlias will be set to true in the for loop because of a. Does this makes sense? Calls were setting Must when all arguments were MustAlias, this patch enables mix of MustAlias and NoAlias arguments. |
The code itself lgtm (and sorry for the earlier braino), but it seems suspect to have MustAlias+NoAlias == MustAlias. For loads and stores I thought the rule was that "Ptr <MustAlias> Store" means "Store does not touch any location other than Ptr". However, this interpretation fails to justify what you're doing here -- if we have a call C = @f_argmemonly(p0, p1) and p1 mustlias p1 and noalias p0, we still can't return mustalias for the p0/C pair since @f_argmemonly(p0, p1) does touch a location other than p1 (i.e. p0). It could be that I'm missing something basic here, like last time.
lib/Analysis/AliasAnalysis.cpp | ||
---|---|---|
193 | Sorry, I must have misread the code. This lgtm. |
Let me start of with saying, I'm not sure this is the right thing to do, you're not missing anything (and sorry for the delayed reply).
The reason I say this, is that I've had the argument with myself both ways, and both make sense depending on how we end up using this Must bit information.
Taking your example, if we have a call C = @f_argmemonly(p0, p1) and p1 mustalias p1 and noalias p0, yes, @f_argmemonly(p0, p1) does touch p0.
If we look at something like promotion, p1 should be ok to be promoted to a scalar based on finding MustAlias+NoAlias with p0. I believe this was the original reason for this patch.
If we look at something like hoisting the call, then we need a getModRef result on all function arguments. This could potentially be an additional API call.
For 2 calls, there's another discussion. Before patch: Must set means "there is a single location both calls touch, and the calls touch no other locations."
After this patch: Must set means "there exists at least one memory location that is touched by both calls, and both calls may each touch a set of disjoint memory locations".
I'm not sure how to use either info off the top of my head, so can't make the argument for/against here..
Is this bit changing behavior? Both before and after we look at IsMustAlias only when DoesAlias is true, and your change only possibly changes the value of IsMustAlias in the cases where DoesAlias is false.