Re: [dataflow] [RFC] Remove many almost useless DCE passes

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Vladimir Makarov wrote:
> Steven Bosscher wrote:
>
>> On 2/27/07, Vladimir Makarov <vmakarov@redhat.com> wrote:
>>
>>> I  am
>>> sure it will be even bigger after the patch.
>>
>>
>> Since you keep asking for the numbers, perhaps you should show some
>> numbers too to back up this kind of assertions ;-)
>
> I did not asked the numbers.  I have them a lot.  I asked what
> benchmarks and platforms do you use to measure the compiler speed
> because I heard several time that df-branch is close to the target. 
> And I still did not get the answer.
>
> Here is the numbers for the code size for x86_64 (text segment) change
> after applying the patch.
>
> ----------------CINT2000-----------------
> 0.042%          37973          37989 164.gzip
> =0.000%         142631         142631 175.vpr
> -0.005%        1419418        1419354 176.gcc
> =0.000%          12040          12040 181.mcf
> 0.047%         171011         171091 186.crafty
> 0.016%         101146         101162 197.parser
> 0.000%         424185         424185 252.eon
> 0.015%         549161         549241 253.perlbmk
> -0.003%         479165         479149 254.gap
> 0.003%         546694         546710 255.vortex
> =0.000%          31258          31258 256.bzip2
> Average = 0.00762539%
>
>>
>> BTW we have a pretty good clue where the code size increase you're
>> seeing comes from, btw.  I am working on a fix, in fact.
>>
>
>
I can see how stock traders have anxiety about leaving their jobs even
for lunch.  I take off the morning to go out skiing and there has been
another battle royal waged just in time i was gone. Let me make some
high level comments. 

At no point in time has it been my goal or the goal of this dataflow
branch to be an apples and apples comparison with the old backend.  We
are producing more information (2 dataflow problems are being kept up to
date rather than one). The information is always correct and can be
relied upon anywhere in the back end.  Moreover, this information is
available over a much larger area of the back end. 

All of this comes with a cost.  Some of that cost is absorbed by the
fact that better algorithms are used to compute the dataflow info, but
some of the gain needs to come from removing some of the stuff that was
done in a stupid manner because dataflow was just not available. 

I understand that this makes a "fair" comparison impossible.  I care
nothing about fairness.  All that I care about is that any problems that
may arise when this patch goes in are manageable and within the
guidelines set forth by the steering committee and that this technology
provides opportunities for better technology to be inserted in the
compiler in the this cycle and in future cycles.

 
Kenny