From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44847 invoked by alias); 3 Sep 2017 11:05:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 44352 invoked by uid 89); 3 Sep 2017 11:05:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,BODY_8BITS,GARBLED_BODY,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=pursue, H*f:sk:14d63d4, H*i:sk:14d63d4, hurry X-HELO: mail-pg0-f47.google.com Received: from mail-pg0-f47.google.com (HELO mail-pg0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 03 Sep 2017 11:05:10 +0000 Received: by mail-pg0-f47.google.com with SMTP id t3so11755508pgt.0 for ; Sun, 03 Sep 2017 04:05:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9Qkg7I8VS/5+bb7K8j2Ggg9AjH96bzOiBj1tCypsNNc=; b=r1jquP0OS65q865byvrtrTuX12cisj3M1KCGuJc6ZirKU1qO63/N+49goU0I1qzXyG OYpHVBFC2AMWEijeFq6x9RuCf61VLqufYqxeGxwus9GnE6bOd9poJwQlY6PoddVvs4ok hQVN4Von8fScjjYnfd49yMlBdKjYBsa38TRDWSQCQzhufsMquXbu27W/yUpKzi8lkgcU 8rVxScYNXkRlYAK+MaATuo/Sx7WJm5ZoLtaOZKzTg39qfzaO71jH7EWioAZUtR/py6sc QnBpBx2rNLBUsuo9LbyfEjePMq0Ttbx3tn+oc6Xjt8c7OnxcVCyjAihDkZ7IO3UZQV/e 36GA== X-Gm-Message-State: AHPjjUjy10cKwTpFJvSUYpKizdeJNn4uYZqwYpdD4D4Vr7OTA1BMAiXd TxE4WJKB4BOykRZa1p2bbuxeSky6UiyR X-Google-Smtp-Source: ADKCNb6IasCeP3QwzkKx6O5crN8J7/UvfA8kzHJ21FcSH/gKC7/KDHgYruT2WEhLLWrNwOsNeSX0wYnwoVqhlR0pJHw= X-Received: by 10.99.163.26 with SMTP id s26mr5977444pge.445.1504436708404; Sun, 03 Sep 2017 04:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.237.144 with HTTP; Sun, 3 Sep 2017 04:04:47 -0700 (PDT) In-Reply-To: <14d63d4d-aef0-4a82-b553-67d98da3cf42.weixi.wwx@antfin.com> References: <234840fd-a06a-4dfd-a1c5-254e26144754.weixi.wwx@antfin.com> <887030ab-6bae-4dd5-b347-05bfad034603.weixi.wwx@antfin.com> <20170901162318.GN2323@tucnak> <20170903100121.GU2323@tucnak> <14d63d4d-aef0-4a82-b553-67d98da3cf42.weixi.wwx@antfin.com> From: "Dmitry Vyukov via gcc-patches" Reply-To: Dmitry Vyukov Date: Sun, 03 Sep 2017 11:05:00 -0000 Message-ID: Subject: Re: Add support to trace comparison instructions and switch statements To: =?UTF-8?B?5ZC05r2N5rWgKOatpOW9vCk=?= Cc: Jakub Jelinek , gcc , gcc-patches , Jeff Law , wishwu007 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00120.txt.bz2 On Sun, Sep 3, 2017 at 12:38 PM, =E5=90=B4=E6=BD=8D=E6=B5=A0(=E6=AD=A4=E5= =BD=BC) wrote: > Hi > I will update the patch according to your requirements, and with some my = suggestions. > It will take me one or two days. Thanks! No hurry, just wanted to make sure you still want to pursue this. > Wish Wu > > ------------------------------------------------------------------ > From:Dmitry Vyukov > Time:2017 Sep 3 (Sun) 18:21 > To:Jakub Jelinek > Cc:Wish Wu ; gcc ; gcc-patches ; Jeff Law ; wishwu007 > Subject:Re: Add support to trace comparison instructions and switch state= ments > > > On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote: >> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote: >>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >>>> What we instrument in LLVM is _comparisons_ rather than control >>>> structures. So that would be: >>>> _4 =3D x_8(D) =3D=3D 98; >>>> For example, result of the comparison can be stored into a bool struct >>>> field, and then used in branching long time after. We still want to >>>> intercept this comparison. >>> >>> Then we need to instrument not just GIMPLE_COND, which is the stmt >>> where the comparison decides to which of the two basic block successors= to >>> jump, but also GIMPLE_ASSIGN with tcc_comparison class >>> gimple_assign_rhs_code (the comparison above), and maybe also >>> GIMPLE_ASSIGN with COND_EXPR comparison code (that is say >>> _4 =3D x_1 =3D=3D y_2 ? 23 : _3; >>> ). >>> >>>> > Perhaps for -fsanitize-coverage=3D it might be a good idea to force >>>> > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE >>>> > decisions mentioned above so that the IL is closer to what the user = wrote. >>>> >>>> If we recurse down to comparison operations and instrument them, this >>>> will not be so important, right? >>> >>> Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_CO= ND, >>> then you don't handle many comparisons from the source code. And if you >>> handle both, some of the GIMPLE_CONDs might be just artificial comparis= ons. >>> By pretending small branch cost for the tracing case you get fewer >>> artificial comparisons. >> >> >> Are these artificial comparisons on BOOLEAN_TYPE? I think BOOLEAN_TYPE >> needs to be ignored entirely, there is just like 2 combinations of >> possible values. >> If not, then what it is? Is it a dup of previous comparisons? >> >> I am not saying these modes should not be enabled. You know much >> better. I just wanted to point that that integer comparisons is what >> we should be handling. >> >> Your example: >> >> _1 =3D x_8(D) =3D=3D 21; >> _2 =3D x_8(D) =3D=3D 64; >> _3 =3D _1 | _2; >> if (_3 !=3D 0) >> >> raises another point. Most likely we don't want to see speculative >> comparisons. At least not yet (we will see them once we get through >> the first comparison). So that may be another reason to enable these >> modes (make compiler stick closer to original code). > > Wait, it is not speculative in this case as branch is on _1 | _2. But > still, it just makes it harder for fuzzer to get through as it needs > to guess both values at the same time rather then doing incremental > progress.