From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117158 invoked by alias); 27 Oct 2017 10:51:38 -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 117082 invoked by uid 89); 27 Oct 2017 10:51:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=grateful X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Oct 2017 10:51:36 +0000 Received: by mail-wm0-f44.google.com with SMTP id s66so2709099wmf.5 for ; Fri, 27 Oct 2017 03:51:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RWwwTwUXX6BOkmxY44AU0Z6C4j+Dta/h05DnLY6n87Q=; b=Bf1GGeElGJBVvQ8e9SV6Iv1JDTIhOwAKVZyrF11UQxZ5fuWYg2rb4HehTTEZpHLASR mBA3x76gRVx4QdXGVzUtTKA94sELmwDCSOBVmZD0BTunxWwyV3s6BxQDJBl0UnFRdURq rZVXpLKVbnh2fDOb5ld9UpyKZ5Wz7g//hde6of/asK93zx9BRF7SVyPDU0YY/6TiG0Hz TiLOHl495DFHkoHohxh70115+0IVEc+zf8BzEu2PXixNTEG0rFt6k5RdP955Wd8OfUqE HcNAzhX1O8ZqZZFqoglYFdTkgBtXGqBw/2XOcmLcqrXMCeN6PFNCnaVoYkkj85LK5wle S7Jw== X-Gm-Message-State: AMCzsaVk2BrO1mskWAptBZhNPwuiIqlb0oyf5Jh3AQypTAfWUUqzwlCG UqL/UNumIjWrKyiKNnWQlTLZGPVRHLSPh+ditq3Irw== X-Google-Smtp-Source: ABhQp+QwJo3mUj1unHmKgT9Dl6HhowPCvXfyTS+T3fmU4OWOQQic7bMz+nPs3s3r0l2J+IQtlmD0WtFI/1Z9i896vco= X-Received: by 10.28.10.195 with SMTP id 186mr52548wmk.136.1509101493979; Fri, 27 Oct 2017 03:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.151.103 with HTTP; Fri, 27 Oct 2017 03:51:33 -0700 (PDT) In-Reply-To: <20171025151426.GA80917@kam.mff.cuni.cz> References: <20170929192803.GA92290@kam.mff.cuni.cz> <20171006130409.GB67693@kam.mff.cuni.cz> <20171007182345.GA64513@kam.mff.cuni.cz> <20171024105608.GA62387@kam.mff.cuni.cz> <20171025151426.GA80917@kam.mff.cuni.cz> From: Prathamesh Kulkarni Date: Fri, 27 Oct 2017 10:52:00 -0000 Message-ID: Subject: Re: [RFC] propagate malloc attribute in ipa-pure-const pass To: Jan Hubicka Cc: gcc Patches , Richard Biener Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg02044.txt.bz2 On 25 October 2017 at 20:44, Jan Hubicka wrote: >> On 24 October 2017 at 16:26, Jan Hubicka wrote: >> >> 2017-10-13 Prathamesh Kulkarni >> >> >> >> * cgraph.h (set_malloc_flag): Declare. >> >> * cgraph.c (set_malloc_flag_1): New function. >> >> (set_malloc_flag): Likewise. >> >> * ipa-fnsummary.h (ipa_call_summary): Add new field is_return_callee. >> >> * ipa-fnsummary.c (ipa_call_summary::reset): Set is_return_callee to >> >> false. >> >> (read_ipa_call_summary): Add support for reading is_return_callee. >> >> (write_ipa_call_summary): Stream is_return_callee. >> >> * ipa-inline.c (ipa_inline): Remove call to ipa_free_fn_summary. >> >> * ipa-pure-const.c: Add headers ssa.h, alloc-pool.h, symbol-summary.h, >> >> ipa-prop.h, ipa-fnsummary.h. >> >> (pure_const_names): Change to static. >> >> (malloc_state_e): Define. >> >> (malloc_state_names): Define. >> >> (funct_state_d): Add field malloc_state. >> >> (varying_state): Set malloc_state to STATE_MALLOC_BOTTOM. >> >> (check_retval_uses): New function. >> >> (malloc_candidate_p): Likewise. >> >> (analyze_function): Add support for malloc attribute. >> >> (pure_const_write_summary): Stream malloc_state. >> >> (pure_const_read_summary): Add support for reading malloc_state. >> >> (dump_malloc_lattice): New function. >> >> (propagate_malloc): New function. >> >> (ipa_pure_const::execute): Call propagate_malloc and >> >> ipa_free_fn_summary. >> >> (pass_local_pure_const::execute): Add support for malloc attribute. >> >> * ssa-iterators.h (RETURN_FROM_IMM_USE_STMT): New macro. >> >> >> >> testsuite/ >> >> * gcc.dg/ipa/propmalloc-1.c: New test-case. >> >> * gcc.dg/ipa/propmalloc-2.c: Likewise. >> >> * gcc.dg/ipa/propmalloc-3.c: Likewise. >> > >> > OK. >> > Perhaps we could also add -Wsuggest-sttribute=malloc and mention it in changes.html? >> Done in this version. >> In warn_function_malloc(), I passed false for known_finite param to >> suggest_attribute(). >> Does that look OK ? >> Validation in progress. OK to commit if passes ? > > OK, thanks! Thanks, committed as r254140 after following validation: 1] Bootstrap+test with --enable-languages=all,ada,go on x86_64-unknown-linux-gnu and ppc64le-linux-gnu. 2] LTO bootstrap+test on x86_64-unknown-linux-gnu and ppc64le-linux-gnu 3] Cross tested on arm*-*-* and aarch64*-*-*. Would it be a good idea to extend ipa-pure-const to propagate alloc_size/alloc_align and returns_nonnull attributes ? Which other attributes would be useful to propagate in ipa-pure-const ? Also, I would be grateful for suggestions on how to propagate malloc attribute through indirect calls. Currently, I have left it as FIXME, and simply drop the lattice to MALLOC_BOTTOM if there's an indirect call :( I am not able to understand how attribute propagation across indirect calls works. For example consider propagation of nothrow attribute in following test-case: __attribute__((noinline, noclone, nothrow)) int f1(int k) { return k; } __attribute__((noinline, noclone)) static int foo(int (*p)(int)) { return p(10); } __attribute__((noinline, noclone)) int bar(void) { return foo(f1); } Shouldn't foo and bar be also marked as nothrow ? Since foo indirectly calls f1 which is nothrow and bar only calls foo ? The local-pure-const2 dump shows function is locally throwing for "foo" and "bar", and ipa-pure-const dump doesn't appear to show foo and bar marked as nothrow. Thanks, Prathamesh > Honza