public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jeff Law <jeffreyalaw@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] introduce predicate analysis class
Date: Fri, 17 Sep 2021 16:05:39 -0600	[thread overview]
Message-ID: <35a69fd0-5f1f-72b3-6325-ace2963b8e49@gmail.com> (raw)
In-Reply-To: <28c6b053-e3de-afe4-b898-0d610ec7381b@gmail.com>

On 9/2/21 10:28 AM, Jeff Law via Gcc-patches wrote:
> 
> 
> On 8/30/2021 2:03 PM, Martin Sebor via Gcc-patches wrote:
>> The predicate analysis subset of the tree-ssa-uninit pass isn't
>> necessarily specific to the detection of uninitialized reads.
>> Suitably parameterized, the same core logic could be used in
>> other warning passes to improve their S/N ratio, or issue more
>> nuanced diagnostics (e.g., when an invalid access cannot be
>> ruled out but also need not in reality be unavoidable, issue
>> a "may be invalid" type of warning rather than "is invalid").
>>
>> Separating the predicate analysis logic from the uninitialized
>> pass and exposing a narrow API should also make it easier to
>> understand and evolve each part independently of the other,
>> or replace one with a better implementation without modifying
>> the other.(*)
>>
>> As the first step in this direction, the attached patch extracts
>> the predicate analysis logic out of the pass, turns the interface
>> into public class members, and hides the internals in either
>> private members or static functions defined in a new source file.
>> (**)
>>
>> The changes should have no externally observable effect (i.e.,
>> should cause no changes in warnings), except on the contents of
>> the uninitialized dump.  While making the changes I enhanced
>> the dumps to help me follow the logic.  Turning some previously
>> free-standing functions into members involved changing their
>> signatures and adjusting their callers.  While making these
>> changes I also renamed some of them as well some variables for
>> improved clarity.  Finally, I moved declarations of locals
>> closer to their point of initialization.
>>
>> Tested on x86_64-linux.  Besides the usual bootstrap/regtest
>> I also tentatively verified the generality of the new class
>> interfaces by making use of it in -Warray-bounds.  Besides there,
>> I'd like to make use of it in the new gimple-ssa-warn-access pass
>> and, longer term, any other flow-sensitive warnings that might
>> benefit from it.
>>
>> Martin
>>
>> [*] A review of open -Wuninitialized bugs I did while working
>> on this project made me aware of a number of opportunities to
>> improve the analyzer to reduce the number of false positives
>> -Wmaybe-uninitiailzed suffers from.
>>
>> [**] The class isn't fully general and, like the uninit pass,
>> only works with PHI nodes.  I plan to generalize it to compute
>> the set of predicates between any two basic blocks.
>>
>> gcc-predanal.diff
>>
>> Factor predidacte analysis out of tree-ssa-uninit.c into its own module.
>>
>> gcc/ChangeLog:
>>
>>     * Makefile.in (OBJS): Add gimple-predicate-analysis.o.
>>     * tree-ssa-uninit.c (max_phi_args): Move to 
>> gimple-predicate-analysis.
>>     (MASK_SET_BIT, MASK_TEST_BIT, MASK_EMPTY): Same.
>>     (check_defs):
>>     (can_skip_redundant_opnd):
>>     (compute_uninit_opnds_pos): Adjust to namespace change.
>>     (find_pdom): Move to gimple-predicate-analysis.cc.
>>     (find_dom): Same.
>>     (struct uninit_undef_val_t): New.
>>     (is_non_loop_exit_postdominating): Move to 
>> gimple-predicate-analysis.cc.
>>     (find_control_equiv_block): Same.
>>     (MAX_NUM_CHAINS, MAX_CHAIN_LEN, MAX_POSTDOM_CHECK): Same.
>>     (MAX_SWITCH_CASES): Same.
>>     (compute_control_dep_chain): Same.
>>     (find_uninit_use): Use predicate analyzer.
>>     (struct pred_info): Move to gimple-predicate-analysis.
>>     (convert_control_dep_chain_into_preds): Same.
>>     (find_predicates): Same.
>>     (collect_phi_def_edges): Same.
>>     (warn_uninitialized_phi): Use predicate analyzer.
>>     (find_def_preds): Move to gimple-predicate-analysis.
>>     (dump_pred_info): Same.
>>     (dump_pred_chain): Same.
>>     (dump_predicates): Same.
>>     (destroy_predicate_vecs): Remove.
>>     (execute_late_warn_uninitialized): New.
>>     (get_cmp_code): Move to gimple-predicate-analysis.
>>     (is_value_included_in): Same.
>>     (value_sat_pred_p): Same.
>>     (find_matching_predicate_in_rest_chains): Same.
>>     (is_use_properly_guarded): Same.
>>     (prune_uninit_phi_opnds): Same.
>>     (find_var_cmp_const): Same.
>>     (use_pred_not_overlap_with_undef_path_pred): Same.
>>     (pred_equal_p): Same.
>>     (is_neq_relop_p): Same.
>>     (is_neq_zero_form_p): Same.
>>     (pred_expr_equal_p): Same.
>>     (is_pred_expr_subset_of): Same.
>>     (is_pred_chain_subset_of): Same.
>>     (is_included_in): Same.
>>     (is_superset_of): Same.
>>     (pred_neg_p): Same.
>>     (simplify_pred): Same.
>>     (simplify_preds_2): Same.
>>     (simplify_preds_3): Same.
>>     (simplify_preds_4): Same.
>>     (simplify_preds): Same.
>>     (push_pred): Same.
>>     (push_to_worklist): Same.
>>     (get_pred_info_from_cmp): Same.
>>     (is_degenerated_phi): Same.
>>     (normalize_one_pred_1): Same.
>>     (normalize_one_pred): Same.
>>     (normalize_one_pred_chain): Same.
>>     (normalize_preds): Same.
>>     (can_one_predicate_be_invalidated_p): Same.
>>     (can_chain_union_be_invalidated_p): Same.
>>     (uninit_uses_cannot_happen): Same.
>>     (pass_late_warn_uninitialized::execute): Define.
>>     * gimple-predicate-analysis.cc: New file.
>>     * gimple-predicate-analysis.h: New file.
> Thanks for tackling this.  It's something I think we've needed for a 
> long time.
> 
> I've only done a cursory review since this is primarily moving the 
> analysis engine to its own file and class-ifying it.
> 
> As we build additional consumers I won't be surprised if we have to 
> adjust the exposed class API, but that's fine.   The first goal is to 
> get the analysis disentangled from the consumer(s).
> 
> OK.  Looking forward to seeing the analysis used elsewhere.

Thanks, I just pushed it.

As a heads up, I've been having some weird email problems lately and
didn't find your approval until today, in my Trash folder.  Just in
case there's fallout that I'm not responsive to, please either ping
me on IRC or email my @redhat account.

Martin

  reply	other threads:[~2021-09-17 22:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 20:03 Martin Sebor
2021-09-02 16:28 ` Jeff Law
2021-09-17 22:05   ` Martin Sebor [this message]
2021-09-18  4:08     ` Jeff Law
2021-09-18 18:46       ` Martin Sebor
2021-09-18 21:14         ` Martin Sebor
2021-09-19 23:24           ` Martin Sebor
2021-11-25 10:18 ` Richard Biener
2021-11-29 15:40   ` Martin Sebor
2021-11-30  7:39     ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35a69fd0-5f1f-72b3-6325-ace2963b8e49@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).