[llvm-dev] RFC: EfficiencySanitizer

[Craig, Ben via llvm-dev]

On 4/18/2016 1:02 PM, Derek Bruening wrote:
> On Mon, Apr 18, 2016 at 1:36 PM, Craig, Ben via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>
>>     *Working set measurement*: this tool measures the data working
>>     set size of an application at each snapshot during execution.  It
>>     can help to understand phased behavior as well as providing basic
>>     direction for further effort by the developer: e.g., knowing
>>     whether the working set is close to fitting in current L3 caches
>>     or is many times larger can help determine where to spend effort.
>     I think my questions here are basically the reverse of my prior
>     questions.  I can imagine the presentation ( a graph with time on
>     the X axis, working set measurement on the Y axis, with some
>     markers highlighting key execution points).  I'm not sure how the
>     data collection works though, or even really what is being
>     measured.  Are you planning on counting the number of data bytes /
>     data cache lines used during each time period?  For the purposes
>     of this tool, when is data brought into the working set and when
>     is data evicted from the working set?
>
>
> The tool records which data cache lines were touched at least once 
> during a snapshot (basically just setting a shadow memory bit for each 
> load/store).  The metadata is cleared after each snapshot is recorded 
> so that the next snapshot starts with a blank slate.  Snapshots can be 
> combined via logical or as the execution time grows to adaptively 
> handle varying total execution time.
So I guess a visualization of that information could show how much new 
memory was referenced per snapshot, how much was the same from a prior 
snapshot, and how much was "dropped".  Neat.


Some other things that might be useful to look for (unrelated to the 
Working set measurement tool):
* Missed restrict opportunities
With shadow memory, you should be able to track whether there is 
aliasing in practice for a given execution, and whether annotating with 
restrict would reduce the number of loads and stores.

* Missed vectorization opportunities
I'm not exactly sure how you could annotate on this front, but this blog 
post ( 
http://blog.llvm.org/2014/11/loop-vectorization-diagnostics-and.html ) 
describes where some diagnostics are already present.  If you can also 
determine whether those optimizations would be valuable through 
instrumentation, then it could be valuable to report it.

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/915c4bff/attachment.html>