From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29518 invoked by alias); 27 Oct 2017 12:18:17 -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 29490 invoked by uid 89); 27 Oct 2017 12:18:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=feeds, Hx-languages-length:3394 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; Fri, 27 Oct 2017 12:18:14 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 0029C548A64; Fri, 27 Oct 2017 14:18:11 +0200 (CEST) Date: Fri, 27 Oct 2017 12:20:00 -0000 From: Jan Hubicka To: Prathamesh Kulkarni Cc: gcc Patches , Richard Biener Subject: Re: [RFC] propagate malloc attribute in ipa-pure-const pass Message-ID: <20171027121811.GB64719@kam.mff.cuni.cz> References: <20171006130409.GB67693@kam.mff.cuni.cz> <20171007182345.GA64513@kam.mff.cuni.cz> <20171024105608.GA62387@kam.mff.cuni.cz> <20171025151426.GA80917@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2017-10/txt/msg02052.txt.bz2 Prathamesh > > 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 ? Good I did not discourage you by slow review rate (will try to do something about it). I guess alloc_size/alloc_align are obvious candidates. returns_nonnull is a special case of VRP over returns so I would rather like to see ipa-prop/ipa-cp extended to handle return values and this done as a consequence. One interesting case I think we could try to track is what types of exceptions are thrown. Currently if function throws specific exception which is handled by caller, we still think caller may throw because we do not take types into consideration at all. I think that may mark significant portion of functions nothrow as this seems like common coding practice. It would be also nice to cleanup ipa-pure-const. I think one can implement propagation template where one just feeds the basic parameters (what data to store, what edges to consider) rahter than copying the rather outdated code again and again. > > 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 ? Well, foo may have other uses where it calls something else than f1 so one needs to track "nothrow in the context when f1 is called". In general I think this reduces to may edges in the callgraph (for given indirect calls we want to track whether we know complete list of possible targets). We do that for polymorphic calls via ipa-polymorphic-call analysis but I did not get around implementing anything for indirect calls. To ge the list of targets, you call possible_polymorphic_call_targets which also tells you whether the list is complete (final flag) or whether there may be some callees invisible to compiler (such as derrivate types from other compilation unit). The lists may be large and for that reason there is cache token which tells you if you see same list again. Extending ipa-pure-const to work across final lists of polymorphic targets may be first step to handle indirect calls in general. Honza > > 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