Re: [PATCH] Cleanup fold_rtx, 1/n

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 13 Apr 2005, Steven Bosscher wrote:
> My gcov attachment to PR19721 shows that the code does not
> trigger on amd64 either.

Hi Paolo and Steven,

I'm still reading through the patch, but I think the wider issue
of using profiling to determine which of GCC's transformations are
worthwhile and which are not deserves some broader discussion.

I admit that fold_rtx is perhaps a special case, as we're trying
to eliminate/reduce the significant amount of compile-time spent
in CSE.  More generally, I'm uncomfortable with using profile
techniques that determine whether a piece of code ever triggers
to decide whether it has benefit or not.  Such protocols are
inherently dependent upon the source code corpus being used.
In this case the comments in PR19271, suggest that you're using
571 source files from GCC's own cc1.

I suspect that in this entire "coverage suite", there isn't a
single "complex" or "vector" operation, and the total number of
floating point operations is severely under-represented compared
to SPECfp for example.  We know that cc1 doesn't link against
the host's libm, for example, so none of GCC's math builtins
would be triggered.

A slightly better approach would be to include the dejagnu
testsuite in the coverage analysis, as the preferred policy of
adding a new testcase to trigger each transformation/optimization
might help here.  Of course, this policy isn't rigorously enforced,
so I'd still be uncomfortable removing code based simply on the
fact that we couldn't get it to trigger.


Of course, there are no clear black-and-whites in such arguments
and everything is a compromise.  For example, even if well-written
pattern matching code should take little extra time if they never
match (e.g. unreachable cases in switch statements), the additional
code leads to larger/slower binaries and presents a maintenance
overhead.  Alternatively, code that never triggers can't cause
any bugs (but may bit-rot until it does trigger at some point in
the future).


My personal preference remains that these RTL optimizations should
be moved from fold_rtx to simplify_rtx when possible, and those that
depend upon the CSE'ing different functional forms are left.  For
example, one of the "???" comments in your patch recommends that that
transformation be moved to combine.c, which is probably as true today
as it was when it was first written.


Thoughts?  Opinions?


I'm not trying to be a road block on the path of progress, but I'd
just like to get a feel for where we intend to draw the line with
these protocols.  If taken to extremes, these policies can clearly
be dangerous (if none of these cc1 files contains K&R prototypes,
perhaps we could drop parser support for pre-ANSI C, etc...).

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833