[trunk] patch to remove REG_NO_CONFLICT_BLOCKS

[Steven Bosscher]

On Wed, Apr 23, 2008 at 12:50 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> I saw the same difference for SH
> too.

OK, I'll see if I can reproduce it with a cross-compiler to SH.  Do
you remember which of the SH targets shows this?

> 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.

The spread in the results for April 22 is quite large (see mcf for
example). There is also a clear positive jump for gcc in SPEC2000, but
that could be a lucky one. I also see no visible effect in 64 bit mode
for SPECINT2000 and a small jump for SPECFP2000.  All of that is
within the noise band width of your tester, AFAICT.  So I wouldn't
jump to the conclusion that there is improvement or degradation until
after a few more SPEC runs.  The code size increase is something we
could take a look at.  This wouldn't be the first time that turning
off part of  the compiler exposes tuning opportunities that went
unnoticed previously.


>  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).

That's not really unexpected.  Without the bits for global, the byte
level df is only used for a byte level DCE, but I don't think there
are any cases in SPEC for which this is likely to do much (except
crafty, maybe).

The slowdown is not good.  We'd have to look into it.  There is still
a lot of room for improvement.  I've been thinking about a
current_function_has_mw_regs or something, that turns this path in the
compiler off in the case that there are no multiword regs to deal with
(i.e. the common case for most architectures).

Gr.
Steven


(P.S. I'd encourage you to try IRA for targets like AVR.  Since IRA
currently doesn't handle REG_NO_CONFLICT-like constructs, it might
have cause some trouble for cute little 8/16 bit AVR, which seems to
more-or-less depend on REG_NO_CONFLICT for many insns...  It is this
kind of regressions that we are trying to avoid with the df byte level
work.)