On Mon, Dec 30, 2013 at 4:29 PM, Ivan Kosarev <[email protected]> wrote: > First of all, let me state it once more that the sanitizers help a lot with > finding bugs in large-scale projects. Thank you gentlemen for your effort! > > Then, one of the ASAN wiki pages at: > > https://code.google.com/p/address-sanitizer/wiki/CompileTimeOptimizations > > discusses some ways to optimize instrumented code and thus addresses > performance matters which is probably the most important issue with > sanitizers. > > I thought that some optimization cases mentioned on this page could be > handled by segregating the sanitizing code from the accesses themselves. In > general, I think the task could be reworded from > > "Sanitize every memory *access*." > > to > > "Sanitize every *address* that is known to be dereferenced. > (And do that as early as possible?)" > > Then, cases like this: > > int glob; > int get_glob() { > return glob; > } > > can be handled trivially as it's known that sanitizing address of a variable > referenced by name is a no-op--even for automatic locals, not just globals. > > Furthermore, there may be interesting consequences from switching to an > approach of this kind. For example, if sanitizing code is segregated from > accesses, then the optimizer has a chance to do some common and uncommon > things about the first. An example for the common case would look like this: > > if (...) > sanitize(a, ...); > *a = ...; > else > sanitize(a, ...); > *a = ...; > > optimized to: > > sanitize(a, ...); > > if (...) > *a = ...; > else > *a = ...; > > Sanitize-specific optimizations would include things like this: > > struct { int a, b; } x; ... > sanitize(&x.a, sizeof(x.a), ...); > x.a = ...; > sanitize(&x.b, sizeof(x.b), ...); > x.b = ...; > > optimized to: > > struct _S { int a, b; } x; ... > sanitize(&x.a, offsetof(_S, b) + sizeof(x.b), ...); > x.a = ...; > x.b = ...; > > etc... > > Will you have a chance, please let me know if you ever did consider this > way.
Thanks, Ivan! Yes, we have considered similar transformations. But did not have resources to try to implement them. However, keep in mind the following aspects: 1. We would prefer to do checks before the memory access in order to not corrupt memory. This rules out some optimizations based on post-dominance. 2. We would like to have precise line number in reports. This rules out some inter-basicblock optimizations. There is still some room for aggregation of accesses to adjacent locations and optimizations based on pre-dominance. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
