public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: "Paulo J. Matos" <pocmatos@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Clustering switch cases
Date: Fri, 27 Aug 2010 15:03:00 -0000	[thread overview]
Message-ID: <mcrhbigt8n2.fsf@google.com> (raw)
In-Reply-To: <AANLkTimSiyGbOTCoSNb5q80YKtvjg46yrVxwbymi2qt=@mail.gmail.com>	(Paulo J. Matos's message of "Fri, 27 Aug 2010 14:39:41 +0100")

"Paulo J. Matos" <pocmatos@gmail.com> writes:

> In the first case, it generates a binary tree, and in the second two
> jump tables. The jump tables solution is much more elegant (at least
> in our situation), generating less code and being faster.
> Now, what I am wondering is the reason why GCC doesn't try to cluster
> the cases trying to find for clusters of contiguous values in the
> switch.
>
> If there is no specific reason then I would implement such pass, which
> would before expansion split switches according to value clustering,
> since I find it would be a good code improvement.
>
> Currently GCC seems to only use jump table is the range of the switch
> is not much bigger than its count, which works well in most cases
> except when you have big switches with clusters of contiguous values
> (like the first example I sent).

I don't know of any specific reason not to look for clusters of switch
cases.  The main issue would be the affect on compilation time.  If you
can do it with an algorithm which is linear in the number of cases, then
I think it would be an acceptable optimization.

Ian

  reply	other threads:[~2010-08-27 14:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-27 13:49 Paulo J. Matos
2010-08-27 15:03 ` Ian Lance Taylor [this message]
2010-08-27 15:09   ` Paulo J. Matos
2010-08-27 15:27   ` Richard Guenther
2010-08-28  0:21     ` Xinliang David Li
2010-08-28 11:08     ` Paulo J. Matos
2010-08-31 15:59       ` Rahul Kharche
     [not found]       ` <201009010034.18924.paul@codesourcery.com>
2010-09-01  8:39         ` Richard Guenther
2010-09-01  9:15           ` Paulo J. Matos
2010-09-01  9:33             ` Richard Guenther
2010-09-01 12:37               ` Paulo J. Matos
     [not found] ` <D84AB18A31AC674EBE9B5300634A800601BF0B0932@EXCHANGEVS.IceraSemi.local>
     [not found]   ` <AANLkTinFhrgJw3Wz8aLhBU6PMYpJzBFTRxLUH3eoz4M0@mail.gmail.com>
     [not found]     ` <4D60B0700D1DB54A8C0C6E9BE691637008965A28@EXCHANGEVS.IceraSemi.local>
     [not found]       ` <AANLkTinkjc4Y9baHXXK7v3ibQNwMtwGhA_oGmaFbykkA@mail.gmail.com>
2010-09-03 10:29         ` Rahul Kharche

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=mcrhbigt8n2.fsf@google.com \
    --to=iant@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=pocmatos@gmail.com \
    /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).