Re: [trunk] patch to remove REG_NO_CONFLICT_BLOCKS

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Vlad,

you have to understand, that steven and I am not trying to write or 
rewrite the register allocator, we are trying to get rid of libcalls and 
the only libcall that people have identified as still necessary is the 
REG_NO_CONFLICT block (which i gather you blow off).

If you had an allocator that worked on all platforms and did not get in 
our way of getting rid of the REG_NO_CONFLICT blocks,  we would have 
moved on to other parts of the problem.    It does not surprise me that 
we have not dotted all of the i's and crossed all the t's on this 
patch.  I have a little over 2 person weeks devoted to this part of it. 

It may be that the right decision is to let REG_NO_CONFLICT blocks be a 
regression.   However we were told that on some platforms on some 
programs, it was important to get this right, and given all of the other 
problems that people have had over the years with local-alloc.c, getting 
rid of it as part of doing the REG_NO_CONFLICT blocks did not seem like 
a completely stupid idea.

We will continue to work on it, but we will do so on the correctness and 
coverage (every platform/every app) first, then we will deal with the 
individual performance issues.   None of the numbers you quote sound 
insurmountable, especially given that we have paid zero attention to 
this so far.

kenny  


Vladimir Makarov wrote:
> Steven Bosscher wrote:
> > On Mon, Apr 21, 2008 at 11:08 PM, Vladimir Makarov 
> > <vmakarov@redhat.com> wrote:
> >  
> > > Please, check c99-int-const-1.c.
> > >     
> >
> > I assume you mean gcc.dg/c99-intconst-1.c
> >
> > I tested it.  cc1 is thoroughly unimpressed at "-O0 -fno-local-alloc"
> > vs. plain "-O0" (obviously, -fno-local-alloc was a quick hack we
> > initially had to disable local-alloc for testing purposes ;-).  The
> > peak memory use is identical, and compile time is consistently
> > *faster* with -fno-local-alloc.
> >
> > This was on i686-pc-cygwin.
> >
> >   
> It should be faster because global processes all pseudo-registers 
> allocated in local-alloc.  It is different from usual approach with 
> local allocator when global and local allocators processing different 
> pseudo sets.  That was major motivation to remove local-alloc for 
> people long ago.  Although in most cases, the speed up is quite 
> insignificant because local is quite fast (e.g. in release mode it 
> gives about 0.3% and 0.2% speedup for SPECINT2000 and SPECFP2000).
>
> As for memory consumption of global used for -O0.   I've checked  
> c99-intconst-1.c on itanium and powerpc cross compilers and saw big 
> difference in peak memory consumption (about 120MB vs about 700MB 
> correspondingly for local and global with -O0).  I am sending memory 
> consumption diagrams in the attachment.  I saw the same difference for 
> SH too.
>
> For -O2 the peak consumption is small (about 30MB).  So before using 
> global allocator for -O0, some optimizations (as I wrote I did not 
> analyzed which ones) should be performed too.  And I don't know is it 
> right thing to do.
> > >  Also a few years ago I did some experiments on removing local-alloc 
> > > too and
> > > I found a visible performance degradation (as I remember about 1%).
> > >
> > >  So removing local-alloc would be a bad idea without performance 
> > > testing.
> > >     
> >
> > Obviously.  Others have done the same testing,
> >
> >   
> I've just checked it again (I applied ra1.diff from Ken's mail at 
> 134529).  And I see about 0.5% degradation for SPECINT2000 and about 
> 1.2% for SPECPF2000 when only global is used.  It was checked on Core2 
> in 32-bit mode with -O2.  The code is also bigger 0.03% and 0.4% 
> correspondingly for SPECINT and SPECFP when only global is used.  So 
> for me obviously that removing local will be unreasonable.
>
> PS: May be it will be interesting for you, but it looks like the byte 
> accurate conflict presentation gives no visible improvement for 
> SPEC2000 on x86/x86_64 but slows down compiler about 0.6% for base and 
> 0.7% for peak on x86_64 (approximately the same number for x86).  You 
> can see it on the tester on http://vmakarov.fedorapeople.org/spec/ 
> (see difference on between Apr21 and Apr22 after Ken applied his patch).