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
