Re: proposal for compilation unil wide alias analyis

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Sat, 26 Jun 2004, Richard Kenner wrote:

> Do you mean GENERIC or GIMPLE here?  I thought the idea was to make the RTL
> expanders accept only GIMPLE.  That will not only make them smaller but
> perhaps faster.  I agree about going into SSA, but I think the cost of going
  ^^^^^^^
As would need to be proven with benchmarks on realistic code before the
patch goes in.  Guessing that something should be an improvement or
shouldn't make things much worse seems like the sort of thing that got us
the terrible long-term performance statistics in bug 15678 (which has an
artificial testcase, but (a) real performance complaints such as from the
OpenBSD people show similar slowdowns, (b) if anything it's more absurd to
have slowed down 21 times at -O0 and 69 times when optimizing for
compiling empty functions, for which the task we do should be no more
complicated than it was in 1988, than for real code which is now checked
against more complicated standards and for which 15 years of new
optimizations might actually have some work to do).  (I haven't yet done 
benchmarks to investigate further why things have persistently slowed down 
so much.)

That said, from a maintenance point of view (trying to get bit-fields to
work when given the correct restricted-width types the C standards give
them) the tree-to-RTL expanders seem rather obscure and full of special
cases piled upon special cases (many of which may be necessary as some
machine-dependencies start being relevant at this point, but they do look
very much like code that has accreted and accumulated these cases over a
long time without an obvious design), and a simplification to take only
GIMPLE would surely make them easier to work on for those who are not
experts in that part of the compiler.  But such a change should be
accompanied by statistics showing that performance does not get worse,
ideally with a comparison to any alternative approaches that may seem
useful for speeding up -O0.

(By way of example, the final removal of stupid.c
<http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00690.html> had statistics
to show a performance improvement, although a previous version had a
performance hit.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)