From: Torbjorn Granlund <tege@nada.kth.se>
To: law@cygnus.com
Cc: mrs@wrs.com (Mike Stump), egcs@cygnus.com
Subject: Re: cc1 hog
Date: Tue, 07 Oct 1997 23:14:00 -0000 [thread overview]
Message-ID: <199710080119.DAA24492@squid.pdc.kth.se> (raw)
In-Reply-To: <5039.876243028@hurl.cygnus.com>
I have been meaning to bring this up for a long time.
The current testing framework is good for catching regressions that cause
miscompilations and compiler crashes. But regressions in code quality will
not be tested for.
I have seen countless examples over the years when a certain optimization is
not effective because some change more or less completely disabled it. I
actually believe GCC would become much better if we spent a larger fraction
of our time studying a set of small code samples to make sure they give
reasonable code. But perhaps we could make something semi-automatic?
I don't think trying to set tight time limits for the c-torture/execute
tests would work in practice. That would be unmanagable. And as Jeff
points out, most tests are tiny and take zero time.
Instead we could introduce a new test category, c-torture/speed. Either we
could maintain a database of timing results, or, perhaps run these tests
using two compilers. One `old' compiler and one `new'. The test framework
would flag whenever the new compiler generates worse code than the old.
Simple and maintenance-free!
The only problem with the latter approach would be accurate-enough timing.
Some CPUs have great features for cycle-exact timing (alpha, perhaps
pentium, and sparcv9 but just under linux since slowaris hides the
register), while on other systems we would have to stick to `getrusage' or
`clock'.
Torbjorn
next prev parent reply other threads:[~1997-10-07 23:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-10-01 15:35 Mike Stump
1997-10-07 11:41 ` Jeffrey A Law
1997-10-07 23:14 ` Torbjorn Granlund [this message]
1997-10-07 23:14 ` Joel Sherrill
1997-10-08 21:19 ` Jeffrey A Law
1997-10-09 9:26 ` Joel Sherrill
-- strict thread matches above, loose matches on Subject: below --
1997-10-01 10:23 Neal Becker
1997-10-01 11:14 ` Joe Buck
1997-10-01 12:12 ` Robert Lipe
1997-10-01 14:23 ` Joe Buck
1997-10-01 12:39 ` Jim Wilson
1997-10-01 12:40 ` Jim Wilson
1997-10-01 14:02 ` Joe Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199710080119.DAA24492@squid.pdc.kth.se \
--to=tege@nada.kth.se \
--cc=egcs@cygnus.com \
--cc=law@cygnus.com \
--cc=mrs@wrs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).