public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c/7344: performance regression on huge case statements Date: Fri, 11 Oct 2002 08:06:00 -0000 [thread overview] Message-ID: <20021011150601.11025.qmail@sources.redhat.com> (raw) The following reply was made to PR c/7344; it has been noted by GNATS. From: Jan Hubicka <jh@suse.cz> To: Jan Hubicka <jh@suse.cz> Cc: Nathanael Nerode <neroden@twcny.rr.com>, gcc-gnats@gcc.gnu.org, rschiele@uni-mannheim.de, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: c/7344: performance regression on huge case statements Date: Fri, 11 Oct 2002 17:01:48 +0200 Hi, this second patch makes CFG construction to take 0.88 second instead of 29 seconds it did originally. Honza Fri Oct 11 16:50:55 CEST 2002 Jan Hubicka <jh@suse.cz> * cfgbuild.c (make_edges): Create edge cache when we do have large jumptable. (do_tablejump): Note size of maximal jumptable. * function.c (prepare_function_start): Zero out size. * function.h (function): Add max_jumptable_ents. Index: cfgbuild.c =================================================================== RCS file: /cvs/gcc/egcs/gcc/cfgbuild.c,v retrieving revision 1.27 diff -c -3 -p -r1.27 cfgbuild.c *** cfgbuild.c 5 Aug 2002 18:46:32 -0000 1.27 --- cfgbuild.c 11 Oct 2002 14:49:54 -0000 *************** make_edges (label_value_list, min, max, *** 292,298 **** /* Heavy use of computed goto in machine-generated code can lead to nearly fully-connected CFGs. In that case we spend a significant amount of time searching the edge lists for duplicates. */ ! if (forced_labels || label_value_list) { edge_cache = sbitmap_vector_alloc (last_basic_block, last_basic_block); sbitmap_vector_zero (edge_cache, last_basic_block); --- 292,298 ---- /* Heavy use of computed goto in machine-generated code can lead to nearly fully-connected CFGs. In that case we spend a significant amount of time searching the edge lists for duplicates. */ ! if (forced_labels || label_value_list || cfun->max_jumptable_ents > 100) { edge_cache = sbitmap_vector_alloc (last_basic_block, last_basic_block); sbitmap_vector_zero (edge_cache, last_basic_block); Index: expr.c =================================================================== RCS file: /cvs/gcc/egcs/gcc/expr.c,v retrieving revision 1.486 diff -c -3 -p -r1.486 expr.c *** expr.c 7 Oct 2002 07:37:09 -0000 1.486 --- expr.c 11 Oct 2002 14:49:57 -0000 *************** do_tablejump (index, mode, range, table_ *** 10941,10946 **** --- 10930,10938 ---- enum machine_mode mode; { rtx temp, vector; + + if (range > cfun->max_jumptable_ents) + cfun->max_jumptable_ents = range; /* Do an unsigned comparison (in the proper mode) between the index expression and the value which represents the length of the range. Index: function.c =================================================================== RCS file: /cvs/gcc/egcs/gcc/function.c,v retrieving revision 1.385 diff -c -3 -p -r1.385 function.c *** function.c 11 Oct 2002 01:28:24 -0000 1.385 --- function.c 11 Oct 2002 14:49:59 -0000 *************** prepare_function_start () *** 6295,6300 **** --- 6295,6302 ---- cfun->function_frequency = FUNCTION_FREQUENCY_NORMAL; + cfun->max_jumptable_ents = 0; + (*lang_hooks.function.init) (cfun); if (init_machine_status) cfun->machine = (*init_machine_status) (); Index: function.h =================================================================== RCS file: /cvs/gcc/egcs/gcc/function.h,v retrieving revision 1.88 diff -c -3 -p -r1.88 function.h *** function.h 22 Sep 2002 14:09:33 -0000 1.88 --- function.h 11 Oct 2002 14:49:59 -0000 *************** struct function GTY(()) *** 500,505 **** --- 500,509 ---- (set only when profile feedback is available). */ FUNCTION_FREQUENCY_HOT } function_frequency; + + /* Maximal number of entities in the single jumptable. Used to estimate + final flowgraph size. */ + int max_jumptable_ents; }; /* The function currently being compiled. */
next reply other threads:[~2002-10-11 15:06 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-10-11 8:06 Jan Hubicka [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-04-08 13:15 hubicka 2003-01-08 2:00 bangerth 2002-10-18 6:56 Robert Schiele 2002-10-18 6:16 Nathanael Nerode 2002-10-17 6:46 Robert Schiele 2002-10-17 6:36 Jan Hubicka 2002-10-17 6:36 Nathanael Nerode 2002-10-17 6:26 Michael Matz 2002-10-17 6:06 Nathanael Nerode 2002-10-15 12:16 Jan Hubicka 2002-10-15 11:56 Kaveh R. Ghazi 2002-10-11 13:26 Richard Henderson 2002-10-11 12:56 Jan Hubicka 2002-10-11 10:26 Richard Henderson 2002-10-11 7:26 Jan Hubicka 2002-10-11 2:26 Jan Hubicka 2002-10-10 19:56 Nathanael Nerode 2002-10-10 19:26 Daniel Berlin 2002-10-10 19:16 Daniel Berlin 2002-10-10 19:16 Daniel Berlin 2002-10-10 19:16 Nathanael Nerode 2002-10-10 19:06 Nathanael Nerode 2002-10-10 19:06 Nathanael Nerode 2002-10-10 18:56 Nathanael Nerode 2002-07-17 13:16 Gerald Pfeifer 2002-07-17 10:46 rschiele
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=20021011150601.11025.qmail@sources.redhat.com \ --to=jh@suse.cz \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /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: linkBe 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).