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: [EMAIL PROTECTED] 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
