
<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


</head>


<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">


<div class="">Working on a downstream optimization which uses CaptureTracking (CT) I came </div>


<div class="">across a coupling problem. It looks like optimizations and analyses which use CT</div>


<div class="">often need to be in sync with CT implementation.</div>


<div class=""><br class="">


</div>


<div class="">Analyzing the uses of the given pointer CT handles three kinds of uses:</div>


<div class=""> * Simple non-capturing use. When one is encountered, CT just moves on.</div>


<div class=""> * Non-capturing, but produces another value, which needs to be tracked. </div>


<div class="">   Examples: bitcasts, geps, phis, selects, etc. I’ll call this kind of uses </div>


<div class="">   "aliases", for the lack of better word.</div>


<div class=""> * Capturing.</div>


<div class=""><br class="">


</div>


<div class="">The "aliases" are tricky. CT users often need to know about these. For example,</div>


<div class=""><a href="https://reviews.llvm.org/rL331587" class="">rL331587</a> taught CT the "alias" semantic of launder.invariant.group calls. </div>


<div class="">Because BasicAA was not aware of this change, it lead to incorrect AA results.</div>


<div class="">"BasicAA still considered every call instruction as a possible escape source and </div>


<div class="">hence concluded that the result of a launder_invariant_group call cannot alias </div>


<div class="">any local non-escaping value."</div>


<div class="">The first attempt to fix it fixed BasicAA (<a href="https://reviews.llvm.org/rL332466" class="">rL332466</a>), but apparently there were </div>


<div class="">similar issues in other parts. These were fixed by <a href="https://reviews.llvm.org/rL333070" class="">


rL333070</a>.</div>


<div class=""><br class="">


</div>


<div class="">Another example is our downstream optimization which does some sort of scalar </div>


<div class="">replacement of non-escaping allocations. It rewrites uses of the allocation and </div>


<div class="">needs to know about "aliases" as their uses also need to be rewritten. Currently </div>


<div class="">it knows about all the "aliases" supported by CT, but it's not resilient to </div>


<div class="">further changes in CT.</div>


<div class=""><br class="">


</div>


<div class="">Proposal</div>


<div class=""><br class="">


</div>


<div class="">Currently CaptureTracker is notified about capturing uses through </div>


<div class="">CaptureTracker::captured. I propose to notify the tracker about all the uses </div>


<div class="">explicitly specifying the kind (NoCapture, Alias, Capture). This way the tracker</div>


<div class="">can only accept Alias uses it knows how to handle. If something unexpected comes</div>


<div class="">up the tracker can give up the analysis.</div>


<div class=""><br class="">


</div>


<div class="">The default tracker can ignore Alias uses under the assumption that upstream</div>


<div class="">users of CT maintain tight coupling with the analysis, like it is today. </div>


<div class="">Refactoring of upstream users of CT is out of scope for this proposal. But in </div>


<div class="">future they can be decoupled from CT implementation by explicitly checking the</div>


<div class="">Alias uses. </div>


<div class=""><br class="">


</div>


<div class="">Thoughts?</div>


<div class=""><br class="">


</div>


<div class="">Artur</div>


</body>


</html>