This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: [gcc3.5 improvement branch] Very Simple constant propagation



On 22/01/2004, at 3:06 PM, Caroline Tice wrote:

Hi Roger,

I have run your patch and my patch on the code that originally caused the problem, and
they generate *exactly* the same .s code. I also ran it on a second version of the test problem,
as well as six of the SPECInt 2000 benchmarks, and in every case they generate exactly
the same .s code. So performance of the compiled code will obviously be identical, and
your patch is smaller and less obtrusive than mine.

However, I have discovered that there seems to be a major difference in compile-time
performance between them. All of these measurements were taken using the "time" command, and done at least three times. I list here the compile times for directly compiling the
SPECInt 2000 benchmarks I measured. I compiled each benchmark directly, using "-O3 -ffast-math -save-temps", and timed the compilation with the 'time" command (i.e. I did NOT use
the SPEC harness to do the compilation). In addition, I passed the "-fss-const-prop" flag to mine to turn on my version (yours is on be default).

Benchmark My Patch Your Patch


gzip 6.65 12.74
[more results, similar]

Thanks for doing this Caroline, it helps a lot!

I think that if both patches produce the same code, I'd really kind of like Roger's patch since it's so much simpler (I've convinced myself that it's probably correct), but if it causes this kind of compile-time regression it really can't be used. I can see how Roger's patch might cause such a regression, but it is still slightly surprising to me. Roger, do you have any suggestions? Did you do any compile time testing?

I presume that Caroline's testing was compiling these programs using intermodule optimisation, so inlining at -O3 will produce large function bodies (like, 100,000 insns).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]