This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Using SPEC CPU2006
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: Mikhail Maltsev <maltsevm at gmail dot com>
- Cc: Vincent Diepeveen <diep at xs4all dot nl>, gcc-help at gcc dot gnu dot org
- Date: Sat, 6 Jun 2015 06:48:17 +0200
- Subject: Re: [RFC] Using SPEC CPU2006
- Authentication-results: sourceware.org; auth=none
- References: <55714E5D dot 1000105 at gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1506060144440 dot 13475 at xs8 dot xs4all dot nl> <55723408 dot 5020307 at gmail dot com>
On 2015.06.06 at 03:43 +0400, Mikhail Maltsev wrote:
> 06.06.2015 3:48, Vincent Diepeveen writes:
> >
> > You sure you want to enter into the tricky world of SPEC testing, where
> > the only way to speed up your compiler is by knowing non-disclosed
> > secrets of CPU's and by in depth studies on optimizations of programs
> > that other than for SPEC really have very little to do with real world
> > optimizations?
> >
> :-) Actually no. For me SPEC is just a good workload for, say,
> regression testing (i.e. if I introduce some changes in optimizations, I
> want to get at least some confirmation, that I did not make the
> generated code worse). For example, right now I want to try to improve
> expansion of string comparison functions like str[n]cmp/memcmp
> (discussed here: https://gcc.gnu.org/ml/gcc/2015-06/msg00054.html). I
> want to use SPEC to gather statistics about use of such functions (i.e.
> what is the average string length, how often are strings compared to
> compile-time constants, what is the average length before first
> mismatch, and so on). Based on this I'll try to optimize existing
> expander and check it on some synthetic benchmarks and then on SPEC.
For a rough estimate there are always the daily SUSE SPEC tests:
http://gcc.opensuse.org/
--
Markus