This is the mail archive of the
mailing list for the GCC project.
Re: Add support to trace comparison instructions and switch statements
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Dmitry Vyukov <dvyukov at google dot com>
- Cc: 吴潍浠(此彼) <weixi dot wwx at antfin dot com>, gcc <gcc at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, wishwu007 <wishwu007 at gmail dot com>
- Date: Sun, 3 Sep 2017 12:01:21 +0200
- Subject: Re: Add support to trace comparison instructions and switch statements
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0EB804ACBA
- References: <email@example.com> <firstname.lastname@example.org> <20170901162318.GN2323@tucnak> <CACT4Y+Y-NUgTakh1t4p+f-6YKuQcULDR0g+nE6iyAud1kMB44g@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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 = x_8(D) == 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 = x_1 == y_2 ? 23 : _3;
> > Perhaps for -fsanitize-coverage= 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_COND,
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 comparisons.
By pretending small branch cost for the tracing case you get fewer