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. > That's all so specialistic and fulltime work - where to start? For me it's still something like a hobby. -- Regards, Mikhail Maltsev
