[llvm-dev] RFC: EfficiencySanitizer

[Filipe Cabecinhas via llvm-dev]

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote:
>> Not when dead store happens in an external DSO where compiler can't detect
>> it (same applies for single references).
>
> Do you mean the ones between the DSO and the instrumented code?
> Because if it's just in the DSO itself, then the compiler could have
> spotted it, too, when compiling the DSO.
>
> I mean, of course there are cases line interprocedural dead-store
> (call a function that changes A while changing A right after), but
> that again, could be found at compilation time, given enough inlining
> depth or IP analysis.
When I read the description, I assumed it would (mostly) be used to
detect those inter-procedural dead-stores, that the compiler can't see
(without LTO, at least).
The "external DSO" case also exists, but unless the DSO is also
instrumented, you'd get lots of false-negatives (which aren't "a big
problem" with the sanitizers, but of course we want to minimize them
(you'd do it by also instrumenting the DSO)).

> Also, if this is not something the compiler can fix, what is the point
> of detecting dead-stores? For all the non-trivial cases the compiler
> can't spot, most will probably arise from special situations where the
> compiler is changing the code to expose the issue, and thus, the user
> has little control over how to fix the underlying problem.
Same as the other sanitizers: The compiler can't fix, but you (the
programmer) can! :-)
I don't think the dead-stores would mostly come from the compiler
changing code around. I think they'd most likely come from the other
example you mentioned, where you call a function which writes
somewhere, and then you write over it, with no intervening read.
If this happens a lot with a given function, maybe you want to write
to some parts of the structure conditionally.



Derek, Qin:
Since this is mostly being researched as it is being implemented (and
in the public repo), how do you plan to coordinate with the rest of
the community? (Current status, what's "left" to get a "useful"
implementation, etc)

About the working set tool:
How are you thinking about doing the snapshots? How do you plan to
sync the several threads?
Spawning an external process/"thread" (kind of like LSan), or internally?

About the tools in general:
Do you expect any of the currently planned ones to be intrusive, and
require the user to change their code before they can use the tool
with good results?

Thank you,

  Filipe