On Thu, Aug 14, 2014 at 11:55 PM, Yuri Gribov <tetra2...@gmail.com> wrote: > On Thu, Aug 14, 2014 at 8:53 PM, Konstantin Serebryany > <konstantin.s.serebry...@gmail.com> wrote: >> In order for your work to be generally useful, I'd ask several things: >> - Update >> https://code.google.com/p/address-sanitizer/wiki/CompileTimeOptimizations >> with examples that will be handled > > Done (to be honest I only plan to do full redundancy elimination for > now, hoisting would hopefully follow later). Note I'm still > experimenting so there may be some changes in actual implementation.
Thanks. if we are running -O0, we should not care about optimizing asan instrumentation. If this is -O1 or higher, then most (but not all) of your cases *should* be optimized by the compiler before asan kicks in. (This may be different for GCC-asan because GCC-asan runs a bit too early, AFAICT. Maybe this *is* the problem we need to fix). If there is a case where the regular optimizer can optimize the code before asan but it doesn't -- we should fix the general optimizer or the phase ordering instead of enhancing asan opt phase. I am mainly interested in cases where the general optimizer can not possibly improve the code, but asan opt can eliminate redundant checks. > >> - Create small standalone test cases in C >> - Don't put the tests under GPL (otherwise we'll not be able to reuse >> them in LLVM) > > I already have a bunch of tests (which I plan to extend further). How > should I submit them s.t. they could be reused by LLVM? Maybe just start accumulating tests on the CompileTimeOptimizations wiki (as full functions that one can copy-paste to a .c file and build)? Once some new optimization is implemented in a compiler X, we'll copy the test with proper harness code (FileCheck/dejagnu/etc) to the X's repository > >>>> make sure that sanopt performs conservative optimization >> Yes. I don't know a good solution to this problem, which is why we did >> not attack it before. >> Increasing asan speed will save lots of CPU time, but missing a single >> software >> bug due to an overly aggressive optimization may cost much more. > > Yeah. I thought about manually inspecting optimizations that are > performed for some large files (e.g. GCC's asan.c) and maybe doing > some random verifications of Asan trophies > (http://code.google.com/p/address-sanitizer/wiki/FoundBugs). Ideally > we'd have some test generator but making a reasonable one for C sounds > laughable. Perhaps there is some prior work on verification of Java > range checks optimizers? There is ton of work for range check optimizers, but none of that fully applies to asan, since asan also checks use-after-free and init-order-fiasco. > > -Y
