This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Asan static optimization (draft)
- From: Yuri Gribov <tetra2005 at gmail dot com>
- To: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- Cc: Yury Gribov <y dot gribov at samsung dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Marek Polacek <polacek at redhat dot com>, Dmitry Vyukov <dvyukov at google dot com>, Dodji Seketeli <dodji at redhat dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>
- Date: Tue, 19 Aug 2014 00:05:56 +0400
- Subject: Re: [PATCH] Asan static optimization (draft)
- Authentication-results: sourceware.org; auth=none
- References: <53E4A5D1 dot 8050007 at samsung dot com> <CAGQ9bdwbhTZUo-To=F87bMu4D0vP7VWydcsaB58+UR_c3AP=qQ at mail dot gmail dot com> <CAJOtW+6X38UHGkXvkpT0J8znfTJjL0VGoR5UEvrB1nPTefHiCA at mail dot gmail dot com> <CAGQ9bdxY_L0DgUQ0-YNjA_=FdeKnJGWRn7B_0dHSgQMDGMKGDA at mail dot gmail dot com>
On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> If this is -O1 or higher, then most (but not all) of your cases
> *should* be optimized by the compiler before asan kicks in.
You mean hoisting memory accesses from branches?
Sure, the tests are simplified beyond all limits.
On the other hand even basic aliasing constraints
would obviously prevent optimization of pointer accesses
(but not of Asan checks!).
> (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).
Thanks for mentioning this, I'll try to experiment
with moving Asan pass across the compilation pipeline and
report my findings.
> I am mainly interested in cases where the general optimizer can not
> possibly improve the code,
> but asan opt can eliminate redundant checks.
As I mentined, I believe that aliasing may often restrict
optimizer's code hoisting ability.
And we certainly need Asan opt for combining checks.
>> 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
Ok, so I'll firstly post tests on wiki and explicitely reference their
origin when submitting patches.
>> 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.
Could you give more details? How would
use-after-free/init-order-fiasco influence verification of redundant
elimination?
-Y