This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR middle-end/11823: Tune jump tables for -Os
- From: Roger Sayle <roger at eyesopen dot com>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 31 Aug 2003 08:36:09 -0600 (MDT)
- Subject: Re: [PATCH] PR middle-end/11823: Tune jump tables for -Os
> Have you considered putting in a comment explaining why the numbers
> chosen for -Os (and not -Os) are appropriate? Otherwise I expect
> someone to look at this code some day and go "Where did these numbers
> come from?" It will also help if this *does* have to be tuned for
> different architectures at some point.
Never trust a magic number over thirty!
Perhaps a better question to a software engineer to ask is not
"Where did these numbers come from?" but "Are these numbers still
relevant?". Change as we all know is inevitable.
In this particular case the bugzilla PR number in the ChangeLog and
the posting on gcc-patches presenting the table of CSiBE benchmark
results should be easy enough to find from CVS. Indeed the first
place that I usually look to find the motivation behind a patch is
the mandatory gcc-patches posting. Its where we usually document
the solutions that weren't used. or that didn't get approved.
The CSiBE (GCC code-size) benchmark is documented on our WWW site:
http://gcc.gnu.org/benchmarks/ Now that we have an code-size
benchmark, I'd hope we'd get used to using it when developing
patches involving optimize_size, much like we use SPECcpu when
evaluating performance improving transformations.