From patchwork Tue Nov 12 12:57:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 1193516 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-513103-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="xEtA3w53"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47C77b56gZz9sNT for ; Tue, 12 Nov 2019 23:57:29 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=ghRs/5GOcXL4ftgmdX1o7plcYllccUQintRpeuPJT/Z8s47JRV7Pi isy840AJOwBxkSuqnBmkHwP8dshL1AZ2kPrHSAWL90uf2i8pW3gQOw95eyFwC5sa i/1ISsJjgFhSluM0lr6+k8AdQVX2VbFN1GIaJh24x3cS1LTtwnkVVA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=uWmj3JB1et+z6puJL8Fe7RrCAUE=; b=xEtA3w53ltFlR4kkfLFs M/fYoGUnHazuP0TtaDLaBIwWiAhRL1f10cJAVF21kUw2p2ZWEz4HxExwsjULCgcH QK0B8VB2n4VjsJWfjHvUfFZiLkqpVcpgPzueiciegnqlJu01EK5yczH7Nd2FaUo2 rsvZWAWK61qcPTfmqNSD1/w= Received: (qmail 68908 invoked by alias); 12 Nov 2019 12:57:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 68897 invoked by uid 89); 12 Nov 2019 12:57:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=worried X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Nov 2019 12:57:21 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 417D72805EE; Tue, 12 Nov 2019 13:57:18 +0100 (CET) Date: Tue, 12 Nov 2019 13:57:18 +0100 From: Jan Hubicka To: gcc-patches@gcc.gnu.org, mjambor@suse.cz, rguenther@suse.de Subject: Teach ipa-cp to propagate value ranges over binary operaitons too Message-ID: <20191112125718.tc3qc6fw7cvqtyrw@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Hi, this patch adds propagation of value ranges through binary operations. This is disabled for value ranges within SCC to avoid infinite loop during propagation. I am bit worried about types here. As far as I can say we have something like VR in lattice of type1 foo (type1 param) { bar ((type3)((type2)param+(type2)4)) } bar (type4 param) { use param.... } Now in code type1 is called "operand_type" and type4 is called param_type. The arithmetics always happens in operand_type but I do not see why these needs to be necessarily the same? Anyway this immitates what constant jump functions does. Also I noticed that we use NOP_EXPR to convert from type1 all the way to type4 while ipa-fnsummary uses VIEW_CONVERT_EXPR to convert type3 to type4 that seems more valid here. However VR folders always returns varying on VIEW_CONVERT_EXPR (which is probably something that can be fixed) Bootstrapped/regtested x86_64-linux. Does this look OK? Honza * ipa-cp.c (propagate_vr_across_jump_function): Also propagate binary operations. Index: ipa-cp.c =================================================================== --- ipa-cp.c (revision 278094) +++ ipa-cp.c (working copy) @@ -1974,23 +2039,51 @@ propagate_vr_across_jump_function (cgrap if (jfunc->type == IPA_JF_PASS_THROUGH) { enum tree_code operation = ipa_get_jf_pass_through_operation (jfunc); + class ipa_node_params *caller_info = IPA_NODE_REF (cs->caller); + int src_idx = ipa_get_jf_pass_through_formal_id (jfunc); + class ipcp_param_lattices *src_lats + = ipa_get_parm_lattices (caller_info, src_idx); + tree operand_type = ipa_get_type (caller_info, src_idx); + if (src_lats->m_value_range.bottom_p ()) + return dest_lat->set_to_bottom (); + + value_range vr; if (TREE_CODE_CLASS (operation) == tcc_unary) { - class ipa_node_params *caller_info = IPA_NODE_REF (cs->caller); - int src_idx = ipa_get_jf_pass_through_formal_id (jfunc); - tree operand_type = ipa_get_type (caller_info, src_idx); - class ipcp_param_lattices *src_lats - = ipa_get_parm_lattices (caller_info, src_idx); - - if (src_lats->m_value_range.bottom_p ()) - return dest_lat->set_to_bottom (); - value_range vr; - if (ipa_vr_operation_and_type_effects (&vr, - &src_lats->m_value_range.m_vr, - operation, param_type, - operand_type)) - return dest_lat->meet_with (&vr); + ipa_vr_operation_and_type_effects (&vr, + &src_lats->m_value_range.m_vr, + operation, param_type, + operand_type); + } + /* A crude way to prevent unbounded number of value range updates + in SCC components. We should allow limited number of updates within + SCC, too. */ + else if (!ipa_edge_within_scc (cs)) + { + tree op = ipa_get_jf_pass_through_operand (jfunc); + value_range op_vr (op, op); + value_range op_res,res; + + range_fold_binary_expr (&op_res, operation, operand_type, + &src_lats->m_value_range.m_vr, &op_vr); + ipa_vr_operation_and_type_effects (&vr, + &op_res, + NOP_EXPR, param_type, + operand_type); + } + if (!vr.undefined_p () && !vr.varying_p ()) + { + if (jfunc->m_vr) + { + value_range jvr; + if (ipa_vr_operation_and_type_effects (&jvr, jfunc->m_vr, + NOP_EXPR, + param_type, + jfunc->m_vr->type ())) + vr.intersect (*jfunc->m_vr); + } + return dest_lat->meet_with (&vr); } } else if (jfunc->type == IPA_JF_CONST)