From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32639 invoked by alias); 12 Aug 2016 09:54:13 -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 32628 invoked by uid 89); 12 Aug 2016 09:54:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=variadic, tree-ssa-ccp, treessaccp X-HELO: mail-io0-f177.google.com Received: from mail-io0-f177.google.com (HELO mail-io0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Aug 2016 09:54:02 +0000 Received: by mail-io0-f177.google.com with SMTP id 38so20292913iol.0 for ; Fri, 12 Aug 2016 02:54:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wGrIG8DJ++GzZF0jOuOp3/pwRxQYt+x4FpqIDD5f7SU=; b=T7LxnVThEHNw2yBufEdGTEmxbzaUVr2TCzxCcbm+piVvrKuezRKu3OWBv7B2YR6ERl 4T+5gvMFKs9YdKGUrpcDCJKqVwpY6MZEmeUrT9tG4rBMUbNRenRYFZ7UPRkie9BFSNZ3 12eh7QfU2XOHaJEIEI5c4SubOHP6bmwk/K9CZ5WhUyBuQvSsFzo6DHitdGpJL4979GMZ Gu1oYSiPnV0LFIjBaaJArJN4XPThkv4Q1DF0LvcvecodgPiHCdnTHSkBwX2r9fAqm3aL 0VVlywoJxJSGjNuk/pDYF+SUd/6be9Zw5RZaQiZOYj1m56UdJW0KxU9yR6KQ2EKPrY2R ph5g== X-Gm-Message-State: AEkoousP8SVUBmfYtbIhyaBQ1MyL/2gFN1o7GcuzrxkBept9aZk13Ab9dKLaJNc7+k4h2dRRMJRKmOw/zSyn5lA6 X-Received: by 10.107.14.2 with SMTP id 2mr16274885ioo.181.1470995639721; Fri, 12 Aug 2016 02:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.208.18 with HTTP; Fri, 12 Aug 2016 02:53:58 -0700 (PDT) In-Reply-To: <20160811125540.GA36505@kam.mff.cuni.cz> References: <20160805123655.c3oai3ivvecx6zbh@virgil.suse.cz> <20160808140355.sbi7zufcjeieek2p@virgil.suse.cz> <20160809110933.2dpy7qdepugoknp2@virgil.suse.cz> <20160809181309.erlp4yxnc5otdtxm@virgil.suse.cz> <20160811125540.GA36505@kam.mff.cuni.cz> From: Prathamesh Kulkarni Date: Fri, 12 Aug 2016 09:54:00 -0000 Message-ID: Subject: Re: [RFC] ipa bitwise constant propagation To: Jan Hubicka Cc: Richard Biener , Kugan Vivekanandarajah , gcc Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01002.txt.bz2 On 11 August 2016 at 18:25, Jan Hubicka wrote: >> @@ -266,6 +267,38 @@ private: >> bool meet_with_1 (unsigned new_align, unsigned new_misalign); >> }; >> >> +/* Lattice of known bits, only capable of holding one value. >> + Similar to ccp_lattice_t, mask represents which bits of value are constant. >> + If a bit in mask is set to 0, then the corresponding bit in >> + value is known to be constant. */ >> + >> +class ipcp_bits_lattice >> +{ >> +public: >> + bool bottom_p () { return m_lattice_val == IPA_BITS_VARYING; } >> + bool top_p () { return m_lattice_val == IPA_BITS_UNDEFINED; } >> + bool constant_p () { return m_lattice_val == IPA_BITS_CONSTANT; } >> + bool set_to_bottom (); >> + bool set_to_constant (widest_int, widest_int); >> + >> + widest_int get_value () { return m_value; } >> + widest_int get_mask () { return m_mask; } >> + >> + bool meet_with (ipcp_bits_lattice& other, unsigned, signop, >> + enum tree_code, tree); >> + >> + bool meet_with (widest_int, widest_int, unsigned); >> + >> + void print (FILE *); >> + >> +private: >> + enum { IPA_BITS_UNDEFINED, IPA_BITS_CONSTANT, IPA_BITS_VARYING } m_lattice_val; >> + widest_int m_value, m_mask; > > Please add comment for these, like one in tree-ssa-ccp and mention they are the same > values. > >> + >> + /* For K&R C programs, ipa_get_type() could return NULL_TREE. >> + Avoid the transform for these cases. */ >> + if (!parm_type) >> + return dest_lattice->set_to_bottom (); > > Please add TDF_DETAILS dump for this so we notice if we drop useful info for no > good reasons. It also happens for variadic functions but hopefully not much more. > > The patch is OK with those changes. Hi, The patch broke bootstrap due to segfault while compiling libsupc++/eh_alloc.cc in ipa_get_type() because callee_info->descriptors had 0 length in propagate_bits_accross_call. After debugging a bit, I realized it was incorrect to use cs->callee and using cs->callee->function_symbol() fixed it: (that seemed to match with value of 'callee' variable in propagate_constants_accross_call). - struct ipa_node_params *callee_info = IPA_NODE_REF (cs->callee); + enum availability availability; + cgraph_node *callee = cs->callee->function_symbol (&availability); + struct ipa_node_params *callee_info = IPA_NODE_REF (callee); tree parm_type = ipa_get_type (callee_info, idx); Similarly I wonder if cs->caller->function_symbol() should be used instead of cs->caller in following place while obtaining lattices of source param ? if (jfunc->type == IPA_JF_PASS_THROUGH) { struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller); The patch segfaults with -flto for gcc.c-torture/execute/920302-1.c in ipcp_propagate_stage () while populating info->descriptors[k].decl_or_type because t becomes NULL and we dereference it with TREE_VALUE (t) The test-case has K&R style param declaration. The following change seems to fix it for me: @@ -3235,7 +3235,7 @@ ipcp_propagate_stage (struct ipa_topo_info *topo) if (in_lto_p) { tree t = TYPE_ARG_TYPES (TREE_TYPE (node->decl)); - for (int k = 0; k < ipa_get_param_count (info); k++) + for (int k = 0; k < ipa_get_param_count (info) && t; k++) { gcc_assert (t != void_list_node); info->descriptors[k].decl_or_type = TREE_VALUE (t); Is that change OK ? PS: I am on vacation for next week, will get back to working on the patch after returning. Thanks, Prathamesh > > thanks, > Honza