public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: gcc-patches@gcc.gnu.org, rguenther@suse.de, mjambor@suse.cz
Subject: Re: [RFC] Context sensitive inline analysis
Date: Fri, 27 May 2011 08:31:00 -0000	[thread overview]
Message-ID: <BANLkTinT43++i5ae_xUN_OnyfHzPSc_z3w@mail.gmail.com> (raw)
In-Reply-To: <20110422123553.GB8655@kam.mff.cuni.cz>

On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
> this patch implements infrastructure to summarize function body size&time in a
> way that is sensitive on function context.  At the moment context means
>
>  1) if function is inline or offline
>  2) if some of parameters are known compile time constants.
>
> but we should handle more later.
>
> The analysis is implemented by introducing notion of predicates, that are
> simple logical formulas in conjunctive-disjunctive form on conditions.
> Conditions are simple tests like "function is not inlined" "op0 is not
> constant" "op0 > 6". That is one can express things like "this statement will
> execute if op1 >6 or op0 is not constant".
>
> The patch implements simple infrastructure to represent the predicates.  There
> are hard limits on everything - i.e. there are no more than 32 different
> conditions and no more than 8 clauses.  This makes it possible to test clauses
> by simple logicaloperations on integers and represent predicates at array of 8
> integers thatis very cheap.  The implementation details are quite contained so
> we might relax the limits, but I don't really see a need for that.
>
> The main point of designing this was to allow effective way of evaulating those
> predicates for given context, since this happens many times during inlining,
> and to not make WPA memory usage grow too much.  At the same time I wanted the
> infrastructure to be flexible enough to allow adding more tricks in future.
> Like we might consider extra inlining points if callee uses the argument to
> drive number of iterations of loop or when caller pass a pointer to a static
> variable that might be SRAed after inlining etc. etc.
>
> At the moment only consumer of predicates is size/time vector that is vector
> of simple entries consiting of size, time and predicate.  Function size/time is then
> computed as sum of all entries whose predicate might be true in given context +
> size/time of all call edges (this is because call edges can disappear at different
> conditions or be turned into constant).
>
> I plan to add more uses of predicates in near future - i.e. attaching
> predicates to edges so we know what calls will be optimized out at WPA time.
> Also I plan to use the analysis to drive function clonning (i.e. partial
> specialization): when function is called from several places with the same
> context and the context makes a difference at expected runtime, clone the
> function.
>
> The analysis part deciding on predicates is currently very simple, kind of proof
> of concept:
>
>  1) Every BB gets assigned predicate when it is reachable. At the moment it happens
>    only if the all predecestors of BB are conditionals that tests function
>    parameter.  Obviously we will need to propagate this info for sane results.
>
>  2) Every statement gets assigned predicate when it will become constant. Again
>    it is very simple, only statements using only function arguments are considered.
>    Simple propagation across SSA graph will do better.
>
>  3) Finally the statement is accounted at a predicate that is conjunction of both
>    above.
>  All call statements are accounted unconditoinally because we don't predicate edges, yet.
>
> While computing function sizes is fast, it is not as speedy as original
> "time-benefit".  Small function inliner is quite insane about querying the
> sizes/times again and again while it keeps up to date its queue. For this
> purpose I added cache same way as we already cache function growths.  Not that
> I would not plan to make inliner&badness more sensible here soon.
> So far I did not want to touch the actual heuristics part of inliner and hope to do
> it after getting the infrastructure to the point I want it to be for 4.7.
>
> The patch bootstraps&regtests.  I tested that compile time implication on
> tramp3d is positive (because of caching, without it inliner grows from 1.1% to
> 4% of compile time) I also tested SPECs and there are not great changes, that
> is not bad result given stupidity of the analysis ;).
>
> I will look into Mozilla even though I plan to look into solving scability
> problems of the inliner as followup instead of snowballing this.
>
> I plan to work on the patch little further during weekend, in particular make
> dumps more readable since they got bit convoluted by random formatting. But i
> am sending the patch for comments and I plan to get it finished till next week.
>
> Honza
>
>        * gengtype.c (open_base_files): Add ipa-inline.h include.
>        * ipa-cp.c (ipcp_get_lattice, ipcp_lattice_from_jfunc): Move to ipa-prop.c
>        update all uses.
>        * ipa-prop.c: (ipa_get_lattice, ipa_lattice_from_jfunc): ... here.
>        * ipa-inline-transform.c (inline_call): Use inline_merge_summary to merge
>        summary of inlined function into former caller.
>        * ipa-inline.c (max_benefit): Remove.
>        (edge_badness): Compensate for removal of benefits.
>        (update_caller_keys): Use reset_node_growth_cache/reset_edge_growth_cache.
>        (update_callee_keys): Likewise.
>        (update_all_callee_keys): Likewise.
>        (inline_small_functions): Do not collect max_benefit; do not
>        reset stimated_growth; call free_growth_caches and initialize_growth_caches.
>        * ipa-inline.h (struct condition, type clause_t, struct predicate, struct
>        size_time_entry): New structures.
>        (INLINE_SIZE_SCALE, INLINE_TIME_SCALE, MAX_CLAUSES): New constants.
>        (inline_summary): Remove size_inlining_benefit, time_inlining_benefit and
>        estimated_growth.
>        (edge_growth_cache_entry): New structure.
>        (node_growth_cache, edge_growth_cache): New global vars.
>        (estimate_growth): Turn into inline.
>        (inline_merge_summary, do_estimate_edge_growth, do_estimate_edge_time,
>        initialize_growth_caches, free_growth_caches): Declare.
>        (estimate_edge_growth): Rewrite.
>        (estimate_edge_time): Implement as inline cache lookup.
>        (reset_node_growth_cache, reset_edge_growth_cache): New inline functions.
>        (MAX_TIME): Reduce to allow multiplicatoin by INLINE_SIZE_SCALE.
>        (NUM_CONDITIONS): New constant.
>        (predicate_conditions): New enum.
>        (IS_NOT_CONSTANT): New constant.
>        (edge_removal_hook_holder): New var.
>        (node_growth_cache, edge_growth_cache): New global vars.
>        (true_predicate, single_cond_predicate, false_predicate, not_inlined_predicate,
>        add_condition, add_clause, and_predicates, or_predicates, predicates_equal_p,
>        evaulate_predicate, dump_condition, dump_clause, dump_predicate, account_size_time,
>        evaulate_conditions_for_edge): New functions.
>        (inline_summary_alloc): Move to heap.
>        (inline_node_removal_hook): Clear condition and entry vectors.
>        (inline_edge_removal_hook): New function.
>        (initialize_growth_caches, free_growth_caches): New function.
>        (dump_inline_summary): Update.
>        (edge_execution_predicate): New function.
>        (will_be_nonconstant_predicate): New function.
>        (estimate_function_body_sizes): Compute BB and constantness predicates.
>        (compute_inline_parameters): Do not clear estimated_growth.
>        (estimate_edge_size_and_time): New function.
>        (estimate_calls_size_and_time): New function.
>        (estimate_callee_size_and_time): New function.
>        (remap_predicate): New function.
>        (inline_merge_summary): New function.
>        (do_estimate_edge_time): New function based on...
>        (estimate_edge_time): ... this one.
>        (do_estimate_edge_growth): New function.
>        (do_estimate_growth): New function based on....
>        (estimate_growth): ... this one.
>        (inline_analyze_function): Analyze after deciding on jump functions.
>        (inline_read_section): New function.
>        (inline_read_summary): Use it.
>        (inline_write_summary): Write all the new data.
>        * ipa-prop.c (ipa_get_param_decl_index): Export.
>        (ipa_lattice_from_jfunc): Move here from ipa-cp.c
>        * ipa-prop.h (ipa_get_param_decl_index, ipa_lattice_from_jfunc): Declare.
>        (ipa_get_lattice): Move hre from ipa-cp.c
>        * Makefile.in (GTFILES): Add ipa-inline.h and ipa-inline-analysis.c
>        * params.def (PARAM_EARLY_INLINING_INSNS): Set to 11.
>

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49179


H.J.

  parent reply	other threads:[~2011-05-27  4:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-22 14:17 Jan Hubicka
2011-04-22 21:02 ` Jan Hubicka
2011-04-23  0:14   ` Jan Hubicka
2011-04-23 10:47     ` Richard Guenther
2011-04-23 17:00       ` Jan Hubicka
2011-05-27  8:31 ` H.J. Lu [this message]
2011-05-27  8:52   ` H.J. Lu
2011-09-27 16:20     ` Jan Hubicka
2011-09-28 11:56       ` Richard Sandiford
2011-10-03  8:12         ` Richard Sandiford
2011-04-25 15:35 David Edelsohn
2011-04-26 13:02 ` Jan Hubicka
2011-04-27 13:18 ` Jan Hubicka
2011-04-27 14:38   ` H.J. Lu
2011-04-27 15:46     ` Jan Hubicka
2011-04-28 13:27       ` David Edelsohn
2011-04-28 13:43         ` Jan Hubicka
     [not found]           ` <BANLkTikScRy+QwZiPyGhHhmuu+ACF65HJA@mail.gmail.com>
2011-04-30 13:38             ` Jan Hubicka
2011-04-30 16:38               ` David Edelsohn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTinT43++i5ae_xUN_OnyfHzPSc_z3w@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=mjambor@suse.cz \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).