This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.3.0 Status Report (2007-09-04)
Martin Jambor wrote:
> Well, there's mine :-) Specifically, its the "Switch initializations
> conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html
Do you have an FSF copyright assignment on file? This patch is big
enough that we would not be able to include it without that.
> Jakub Jelinek had a few comments and I changed the patch according to
> them. After that, nothing much happened. If any maintainer likes the
> patch, please commit it as I do not have write access to svn. OTOH, if
> there are any further concerns, please let me know.
I see one technical change that should be made. In particular, please
change:
> +/* We never create arrays larger than the following constant (given in number
> + of elements). */
> +#define MAX_ARRAY_RANGE 0x2000
> +
> +/* We never create arrays if the number of branches is not at least the range
> + divided by the following constant. */
> +#define MAX_RANGE_BRANCH_RATIO 8
to use the --param mechanism. Our policy is to have *no* magic numbers
for these kinds of things. It's easy enough to allow users to use
--param to set the values, and that makes it easy for people (often the
compiler developers themselves) to experiment with the values to help
fine-tune the defaults.
Other than that, the patch looks pretty good to me. However, I'd like a
middle-end maintainer to review the patch. Ian, Diego, Roger, would one
of you please take a look?
Is there any reason to think this patch might generate worse code on
some processors or in some modes? For example, while this patch seems
it's definitely a code-size win for dense switch statements, do we need
some kind of cost model to tell us whether it's a code-size win with
less dense switch statements? Do we want want separate params when
we're operating under -Os from when we're operating under -O2?
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713