<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 2:51 PM, Jia Chen via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grievejia created this revision.<br>
grievejia added reviewers: george.burgess.iv, hfinkel.<br>
grievejia added a subscriber: llvm-commits.<br>
<br>
Unfortunately, the getModRefBehavior() functions for both CFL-AA turn out to be very buggy.<br>
<br>
Currently, getModRefBehavior() is implemented by looking at AliasSummary.RetParamRelations, a vector that records how **pointer values** are accessed. Non-pointer values are simply ignored. As a result, if inside the function we store an i32 to one of the i32* parameter, or if we load an i64 from one of the i64* parameter, the load/store won't be recorded by RetParamRelations since i32 and i64 are scalar types, not pointer types. </blockquote><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we only check RetParamRelations for modref behavior, we will inevitably miss those scalar loads and stores. The takeaway point here is that RetParamRelations is good for summarizing pointer aliases, but cannot be relied on to summarize function modref behaviors.<br>
<br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another problem with our current getModRefBehavior() implementation is that when analyzing modref for function f, it does not consider any functions that are called by f. For example, if f() is a function that calls certain library function with side-effects, those side effects won't be aggregated into f's modref behavior, which is problematic.<br>
<br>
The lesson I learned from debugging those problems is that modref and aliasing are conceptually two different problems. </blockquote><div><br></div><div>yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Aliasing can be used to derive modrefs, but they're still two separate analyses and conflating the two into a single pass doesn't sound like a good idea. </blockquote><div><br></div><div>You should not try to answer modref from points-to sets alone, yes ;)</div><div>They are used as basis sets to compute mod ref info.</div><div><br></div><div>Note that mod-ref can be solved as a reachability problem, but not sure that makes the most sense either.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd say that let's remove the buggy implementation for now until we can come up with a more principled, less error-prone approach .<br>
<br>
<a href="https://reviews.llvm.org/D22978" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22978</a><br>
<br>
Files:<br>
  include/llvm/Analysis/CFLAndersAliasAnalysis.h<br>
  include/llvm/Analysis/CFLSteensAliasAnalysis.h<br>
  lib/Analysis/CFLAndersAliasAnalysis.cpp<br>
  lib/Analysis/CFLSteensAliasAnalysis.cpp<br>
  test/Analysis/CFLAliasAnalysis/Andersen/interproc-ret-arg.ll<br>
  test/Analysis/CFLAliasAnalysis/Andersen/interproc-ret-deref-arg-multilevel.ll<br>
  test/Analysis/CFLAliasAnalysis/Andersen/interproc-ret-deref-arg.ll<br>
  test/Analysis/CFLAliasAnalysis/Andersen/interproc-ret-ref-arg-multilevel.ll<br>
  test/Analysis/CFLAliasAnalysis/Andersen/interproc-ret-ref-arg.ll<br>
  test/Analysis/CFLAliasAnalysis/Andersen/interproc-store-arg.ll<br>
  test/Analysis/CFLAliasAnalysis/Steensgaard/interproc-ret-arg.ll<br>
<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>