[llvm-dev] RFC: EfficiencySanitizer

[Yury Gribov via llvm-dev]

On 04/20/2016 05:07 PM, Filipe Cabecinhas wrote:
> 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.

Sure, I meant inter-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)).

Good point, one (critical) requirement for easy integration is 
scalability - user should not need to recompile full distro to get 
useful info from the tool (not that it's always possible of course). For 
example this is (IMHO) the main obstacle for using MSan in production.

>> 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! :-)

Indeed. Performance engineers (who will be very interested in this tool) 
typically have the luxury of optimizing the code across packages.

> 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
>
>