This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: switch statement performance


Paul Vixie <paul@vix.com> writes:

> today i wanted to go on a performance-related witch hunt, so i added:
> 
> --------
> 
> --- stmt.c.orig Mon Jan 19 19:39:41 2004
> +++ stmt.c      Mon Jan 19 19:57:25 2004
> @@ -5393,6 +5393,12 @@
>                || (TREE_CODE (index_expr) == COMPOUND_EXPR
>                    && TREE_CODE (TREE_OPERAND (index_expr, 1)) == INTEGER_CST))
>         {
> +         /* If the sequence would be absurdly long and slow, send warning.  */
> +         if (extra_warnings
> +             && count >= case_values_threshold ()
> +             && compare_tree_int (range, 10 * count) > 0)
> +           warning ("large range, slow code");
> +
>           index = expand_expr (index_expr, NULL_RTX, VOIDmode, 0);
>  
>           /* If the index is a short or char that we do not have
> 
> --------
> 
> and then ran -W against bind8, bind9, the freebsd kernel, and other smaller
> things.  the results weren't amazing or stupendous, but they were quite
> useful.  one of the things i learned is that a lot of sparse switch stmts
> should be left as they are for cleanliness reasons, since they are not
> inside loops or otherwise called often enough to warrant rewriting them to
> avoid the if-else code generation behaviour signalled by the above warning().

You didn't explain why you wanted to do this, or what problem you're
trying to solve; I feel like this is the last message of a long
discussion.  Are you concerned about the object code quality, or the
quality of the C code that GCC is compiling?

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]