This is the mail archive of the gcc@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: Recent dataflow branch SPEC2000 benchmarking


Steven Bosscher wrote:

On 4/12/07, Steven Bosscher <stevenb.gcc@gmail.com> wrote:

On 4/12/07, Vladimir Makarov <vmakarov@redhat.com> wrote:
> An interesting observation is that the more hard registers the processor
> has, the bigger slowdown is. Although it might be a coincidence.


Yes, I noticed this too.  I don't believe this is a coincidence.  It's
the first thing I was planning to look into, in fact.


The problem seems to have to do with how the RTL loop optimizers work.
They analyze a subcfg with df, and this is incredibly slow right now.

To give you some idea, we spend more than 35% of the total compile
time in "loop analysis" (TV_LOOP) for a fairly typical Fortran 90
program with lots of small loops, and almost all that extra time is
spent in df_reorganize_refs_by_reg.

So, Vlad, thanks for helping us identify a serious bottleneck! Kenny
said he has some ideas about how to fix this.

No problem. New DF infrastructure is inevitable (we differ only in question when to merge). I see a real progress in compilation speed improvement. I am going to do more benchmarking (on merge points) to check the progress.

As you probably saw from my email, there is SPECFP2000 score degradation on ppc64 (all other ports looks good). The biggest degradation is wupwise (about 7%). Wupwise is relatively small program. It would be nice if you fix it.

I also see bigger code size on all platforms. As I wrote if you fix that, you will be closer to 5% target or even there. And ppc is the best platform to do it.


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