From: John Regehr <regehr@cs.utah.edu>
To: Andi Kleen <andi@firstfloor.org>
Cc: gcc@gcc.gnu.org
Subject: Re: detailed comparison of generated code size for GCC and other compilers
Date: Mon, 14 Dec 2009 16:31:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.00.0912140920200.10900@thebes.cs.utah.edu> (raw)
In-Reply-To: <87hbrty1k5.fsf@basil.nowhere.org>
> I wonder if the original program was already broken or was this
> something your conversion introduced?
Not sure about this specific case but I'm sure there's some of each.
I also noticed these testcases but decided to leave them in for now.
Obviously the code is useless, but it can still be interpreted according
to the C standard, and code can be generated. Once you start going down
the road of exploiting undefined behavior to create better code -- and gcc
already does this pretty aggressively -- why not keep going?
That said, if there's a clear sentiment that this kind of test case is
undesirable, I'll make an effort to get rid of these for subsequent runs.
The bottom line is that these results are supposed to provide you folks
with useful directions for improvement.
> Looking further down the table a lot of the differences on
> empty-after-optimization functions (lots of 5 vs 2 bytes) seem to be
> that gcc-head uses frame pointers and the other compiler doesn't.
> Clearly for a fair comparison these settings should be the same.
I wanted to avoid playing flag games and go with -Os (or nearest
equivalent) for all compilers. Maybe that isn't right.
John Regehr
next prev parent reply other threads:[~2009-12-14 16:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-14 15:35 John Regehr
2009-12-14 16:15 ` Andi Kleen
2009-12-14 16:31 ` John Regehr [this message]
2009-12-14 17:17 ` Andi Kleen
2009-12-14 17:46 ` Daniel Jacobowitz
2009-12-14 20:36 ` John Regehr
2009-12-14 21:46 ` Joe Buck
2009-12-14 21:53 ` John Regehr
2009-12-14 22:06 ` Joe Buck
2009-12-15 0:38 ` John Regehr
2009-12-15 6:35 ` Robert Dewar
2009-12-15 10:24 ` Andi Kleen
2009-12-15 11:46 ` Mathieu Lacage
2009-12-15 13:45 ` Andi Kleen
2009-12-15 18:56 ` Andreas Schwab
2009-12-15 6:33 ` Robert Dewar
2009-12-14 20:31 ` John Regehr
2009-12-15 8:28 ` Paolo Bonzini
2009-12-15 8:44 ` Chris Lattner
2009-12-15 9:00 ` Paolo Bonzini
2009-12-15 17:17 ` John Regehr
2009-12-14 17:49 ` Steven Bosscher
2009-12-15 6:30 ` Robert Dewar
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=alpine.DEB.1.00.0912140920200.10900@thebes.cs.utah.edu \
--to=regehr@cs.utah.edu \
--cc=andi@firstfloor.org \
--cc=gcc@gcc.gnu.org \
/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).