[llvm-dev] RFC: EfficiencySanitizer

[Qin Zhao via llvm-dev]

>
>
> Will this technology allow us to pinpoint specific accesses that generally
> have high latency (i.e. generally are cache misses)? This information is
> useful for programmers, and is also useful as an input to loop unrolling,
> instruction scheduling, and the like on ooo cores.
>

Won't hardware performance counter tell you which accesses are delinquent
accesses?
The tools here are trying to provide more information and hopefully some
insight of the performance problem.
For example, if we can tell that the working set of an application is
slightly bigger than the L3 cache, developers would be able to take the
right action to improve the performance.

We are welcome any suggestions about how the information can be used, or
what information should be collected.

Qin


>
>  -Hal
>
> >
> > *Dead store detection*: this tool identifies dead stores
> > (write-after-write patterns with no intervening read) as well as
> > redundant stores (writes of the same value already in memory). Xref
> > the Deadspy paper from CGO 2012.
> >
> >
> > *Single-reference*: this tool identifies data cache lines brought in
> > but only read once. These could be candidates for non-temporal
> > loads.
> >
> >
> > ====================
> > EfficiencySanitizer
> > ====================
> >
> >
> > We are proposing the name EfficiencySanitizer, or "esan" for short,
> > to refer to this suite of dynamic instrumentation tools for
> > improving program efficiency. As we have a number of different tools
> > that share quite a bit of their implementation we plan to consider
> > them sub-tools under the EfficiencySanitizer umbrella, rather than
> > adding a whole bunch of separate instrumentation and runtime library
> > components.
> >
> >
> > While these tools are not addressing correctness issues like other
> > sanitizers, they will be sharing a lot of the existing sanitizer
> > runtime library support code. Furthermore, users are already
> > familiar with the sanitizer brand, and it seems better to extend
> > that concept rather than add some new term.
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> --
> You received this message because you are subscribed to the Google Groups
> "efficiency-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to efficiency-sanitizer+unsubscribe at google.com.
> To post to this group, send email to efficiency-sanitizer at google.com.
> To view this discussion on the web visit
> https://groups.google.com/a/google.com/d/msgid/efficiency-sanitizer/19928798.1837.1461205693345.JavaMail.hfinkel%40sapling5.localdomain
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/55f919dc/attachment.html>