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
On 20 April 2016 at 15:07, Filipe Cabecinhas <filcab at gmail.com> wrote:> 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)).Indeed. cheers, --renato
On Wed, Apr 20, 2016 at 10:07 AM, Filipe Cabecinhas <filcab at gmail.com> wrote:> 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) >Mostly via llvm-dev. Do you have another suggestion? 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? >As requested I sent a separate RFC about the working set tool. Let's discuss on that thread. 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? >No, we do not want to rely on annotations or anything like that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160420/1bab54d8/attachment.html>
On Wed, Apr 20, 2016 at 10:18 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 20 April 2016 at 15:07, Filipe Cabecinhas <filcab at gmail.com> wrote: > > 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)). >We could also perform hybrid execution, i.e., execute the compiler instrumented code natively and execute external DSO code under a dynamic binary instrumentation system like DynamoRIO <http://www.dynamorio.org>. That would be a totally different topic.> Indeed. > > cheers, > --renato > > -- > 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/CAMSE1kfT7NyOMHiZknMXsAADYZXvra559y_%2Bixd5pQZcrdYaAA%40mail.gmail.com > . >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160420/4a1b1282/attachment.html>
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 > >