<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 20, 2016 at 2:14 AM, Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Interesting idea!  I understand how the bookkeeping in the tool is similar to some of the sanitizers but I am wondering whether that is really the best developer’s work-flow for such a tool.</div><div><br></div><div>I could imagine that some of the opportunities discovered by the tool could be optimized automatically by the compiler (e.g. temporal loads, sw prefetching, partitioning the heap) so feeding this information back to the compiler could be highly useful.  I am wondering whether the PGO model is closer to what we want at the end.  The problem can also be thought of as a natural extension of PGO.  Besides instrumenting branches and indirect calls, it adds instrumentation for loads and stores.</div></div></blockquote><div><br></div><div>It would be great to automatically apply the results of the tools, but we do not think that this is straightforward for enough cases up front.  For the cache fragmentation tool, automatically applying data structure field reordering (or splitting or peeling) generally requires whole-program compilation, which is not always available and currently does not scale up to the size of applications we would like to target.  The working set tool is not a candidate for automated action.  Acting on dead stores typically requires programmer analysis to confirm that there is not some non-executed path where the store is not actually dead.</div><div><br></div><div>We would like to start with a standalone sanitizer usage model providing developer feedback.  How about if we start with that and in the future we can revisit whether some subset of the results can be acted on in an automated fashion?</div><div><br></div></div></div></div>