public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).