From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 171623857027 for ; Tue, 27 Oct 2020 18:35:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 171623857027 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09RIXbwp152753; Tue, 27 Oct 2020 14:35:04 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 34efx4bvbs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 14:35:04 -0400 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 09RIZ3Gr157224; Tue, 27 Oct 2020 14:35:03 -0400 Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com with ESMTP id 34efx4bvah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 14:35:03 -0400 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 09RIYaI4012629; Tue, 27 Oct 2020 18:35:01 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma02fra.de.ibm.com with ESMTP id 34cbw89vn8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 18:35:01 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 09RIYw8p31195512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Oct 2020 18:34:58 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CB5D252052; Tue, 27 Oct 2020 18:34:58 +0000 (GMT) Received: from sig-9-145-1-210.uk.ibm.com (unknown [9.145.1.210]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 90C565204E; Tue, 27 Oct 2020 18:34:58 +0000 (GMT) Message-ID: <4ce44dda24d28279156422c10d09d64a575f1f8c.camel@linux.ibm.com> Subject: Incremental updating of SSA_NAMEs that are passed to b_c_p From: Ilya Leoshkevich To: gcc@gcc.gnu.org Cc: Jeff Law , Marc Glisse Date: Tue, 27 Oct 2020 19:34:58 +0100 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-27_10:2020-10-26, 2020-10-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 spamscore=0 impostorscore=0 clxscore=1011 mlxlogscore=999 adultscore=0 lowpriorityscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010270107 X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 18:35:06 -0000 Hi, I'd like to revive the old discussion regarding the interaction of jump threading and b_c_p causing the latter to incorrectly return 1 in certain cases: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549288.html The conclusion was that this happening during threading is just a symptom of a deeper problem: SSA_NAMEs that are passed to b_c_p should not be registered for incremental updating. I performed a little experiment and added an assertion to create_new_def_for: --- a/gcc/tree-into-ssa.c +++ b/gcc/tree-into-ssa.c @@ -2996,6 +3014,8 @@ create_new_def_for (tree old_name, gimple *stmt, def_operand_p def) { tree new_name; + gcc_checking_assert (!used_by_bcp_p (old_name)); + timevar_push (TV_TREE_SSA_INCREMENTAL); if (!update_ssa_initialized_fn) This has of course fired when performing basic block duplication during threading, which can be fixed by avoiding duplication of basic blocks wi th b_c_p calls: --- a/gcc/tree-cfg.c +++ b/gcc/tree-cfg.c @@ -6224,7 +6224,8 @@ gimple_can_duplicate_bb_p (const_basic_block bb) || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT) || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY) || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_BFLY) - || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_IDX))) + || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_IDX) + || gimple_call_builtin_p (g, BUILT_IN_CONSTANT_P))) return false; } The second occurrence is a bit more interesting: gimple * vrp_insert::build_assert_expr_for (tree cond, tree v) { ... a = build2 (ASSERT_EXPR, TREE_TYPE (v), v, cond); assertion = gimple_build_assign (NULL_TREE, a); ... tree new_def = create_new_def_for (v, assertion, NULL); The fix is also simple though: --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -3101,6 +3101,9 @@ vrp_insert::process_assert_insertions_for (tree name, assert_locus *loc) if (loc->expr == loc->val) return false; + if (used_by_bcp_p (name)) + return false; + cond = build2 (loc->comp_code, boolean_type_node, loc->expr, loc- >val); assert_stmt = build_assert_expr_for (cond, name); if (loc->e) My original testcase did not trigger anything else. I'm planning to check how this affects the testsuite, but before going further I would like to ask: is this the right direction now? To me it looks a little-bit more heavy-handed than the original approach, but maybe it's worth it. Best regards, Ilya