Re: PR 23551: why should we coalesce inlined variables?

[Alexandre Oliva <aoliva at redhat dot com>]

On May 16, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:

> On Tue, 2007-05-15 at 02:41 -0300, Alexandre Oliva wrote:
>> On May 10, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
>> 
>> > On Thu, 2007-05-10 at 04:39 -0300, Alexandre Oliva wrote:
>> >> We're discarding useful debug info by SSA-coalescing inlined
>> >> variables.  The reason we refrain from coalescing non-inlined
>> >> variables is for better debug info.  No other pass pays attention to
>> >> DECL_FROM_INLINE, and it doesn't look like we generate significantly
>> >> worse code if we refrain from coalescing these variables.  So...

>> >> May I check this in if it passes bootstrap and regression testing on
>> >> x86_64-linux-gnu?

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00703.html

> Runtime performance is the original reason for this code.  Have we
> got a spec run or anything like that which shows no degradation on
> non-trival tests?

I didn't.  Today I set some time aside to try to get SPEC2000 to run
on an x86_64 box with Fedora 7.  I still haven't got all of the
benchmarks to compile and run successfully with the GCC trunk, but the
results I got for the patch are promising:

test.run.reported_time: with.patch without.patch

$ join <(grep reported_time result/CINT2000.01{8,9}.raw ) |
> sed '/--/d;s,spec.cpu2000.results.,,;s,.base,,'
164_gzip.000.reported_time: 144.011922 146.960834
164_gzip.001.reported_time: 142.690997 148.162698
164_gzip.002.reported_time: 142.478545 144.370832
175_vpr.000.reported_time: 165.572083 172.934489
175_vpr.001.reported_time: 164.816851 178.515859
175_vpr.002.reported_time: 167.31685 179.519917
176_gcc.000.reported_time: 81.173042 83.914689
176_gcc.001.reported_time: 85.537434 83.364006
176_gcc.002.reported_time: 81.846146 82.77694
181_mcf.000.reported_time: 270.265061 276.120451
181_mcf.001.reported_time: 270.013627 283.283258
181_mcf.002.reported_time: 269.280434 282.067706
186_crafty.000.reported_time: 71.552723 73.565062
186_crafty.001.reported_time: 72.104663 73.030409
186_crafty.002.reported_time: 71.700514 73.234561
197_parser.000.reported_time: 192.88753 197.16774
197_parser.001.reported_time: 192.959393 196.33103
197_parser.002.reported_time: 194.97802 199.367935
254_gap.000.reported_time: 75.084207 83.250747
254_gap.001.reported_time: 75.146032 82.405347
254_gap.002.reported_time: 73.328896 81.14021
256_bzip2.000.reported_time: 130.042612 133.799692
256_bzip2.001.reported_time: 130.426055 133.950122
256_bzip2.002.reported_time: 130.058703 136.170359

$ join <(grep reported_time result/CFP2000.01{8,9}.raw ) |
> sed '/--/d;s,spec.cpu2000.results.,,;s,.base,,'
177_mesa.000.reported_time: 94.977814 96.983933
177_mesa.001.reported_time: 95.24262 96.617943
177_mesa.002.reported_time: 94.312482 98.390187
179_art.000.reported_time: 147.139964 162.502551
179_art.001.reported_time: 151.263697 153.911989
179_art.002.reported_time: 148.459108 157.28408
183_equake.000.reported_time: 68.897749 72.475304
183_equake.001.reported_time: 69.109982 71.188666
183_equake.002.reported_time: 69.106592 70.759088
188_ammp.000.reported_time: 177.48807 182.399815
188_ammp.001.reported_time: 179.004766 182.887323
188_ammp.002.reported_time: 178.414388 183.0444

Again, the left column is the run-time WITH the patch, the right
columnt is the run-time WITHOUT the patch.  That's right, removing the
patch actually slows things down.  I couldn't quite believe it, after
what you said, so I triple-checked.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}