public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: law@redhat.com
To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Cc: jh@suse.cz, gcc@gcc.gnu.org
Subject: Re: An issue for the SC: horrible documentation quality of GCC
Date: Mon, 12 May 2003 17:39:00 -0000	[thread overview]
Message-ID: <200305121736.h4CHa8CZ016317@speedy.slc.redhat.com> (raw)
In-Reply-To: Your message of "Fri, 09 May 2003 22:25:56 EDT." <10305100225.AA20837@vlsi1.ultra.nyu.edu>

In message <10305100225.AA20837@vlsi1.ultra.nyu.edu>, Richard Kenner writes:
 >    Then you will end up with never ending dataflow problems in the global
 >    pass.  The GCSE in the simplest definition is already too complicated
 >    for us to be implemented correctly (we are on it since 97 and still it
 >    is inferrior to what is done by other compilers).  Adding more
 >    complexity, like CSE has would make it more crazier.
 >
 >Perhaps, but a lot of that complexity is *needed*.  The reason that GCC
 >has historically beaten other compilers in code quality is paying attention 
 >to important heuristics and less on "textbook" material.  Sure the latter
 >is also critical, but the pragmatics cannot be ignored.
Note, I would disagree with the statement "GCC has historically beaten
other compilers in code quality".

In my experience of looking at GCC against compilers from multiple vendors,
including HP, IBM, Intel, Sun and others, GCC has consistently performed
slightly worse for integer codes (assuming you didn't turn on any
intra-procedural optimizations in the competing compiler).  The difference
in performance is small, but measurable (typically around 5%).  Clearly in
some cases GCC does better and in some cases the competing compiler does
better, but the overall picture I've seen has GCC performing slightly worse.

In those same comparisons, but using FP intensive code, GCC's performance
is significantly worse -- on the order of 10-15% worse.

When I've analyzed the codes in question, the inability to spot and remove
higher level redunancies is one of the major issues, along with register
allocation and good scheduling.


 >    CSE does a lot and is powerfull pass that does approximately what is
 >    accomplished by multiple passes as described in literature.  The
 >    problem is that we don't know how to make it global and/or faster and
 >    we know that it is too slow right now.
 >
 >A lot of the slowness is due to the "global" parts of its activities.  I've
 >suggested a number of times that they be turned off since they would seem
 >redundant with GCSE.  But when this is tried, it lowers performance, which
 >certainly suggests that the "complexity" of CSE is worth something.
The global nature of CSE is not redundant with GCSE.  It never has been.

Roger's recent changes (jump bypassing I believe) got us closer, but
there are still a couple important cases that CSE handles that GCSE
does not.  I believe Richard Henderson outlined those in a message to
the GCC lists sometime in the last couple months.


Jeff


  parent reply	other threads:[~2003-05-12 17:39 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-10  2:21 Richard Kenner
2003-05-10 15:12 ` Zdenek Dvorak
2003-05-12 16:05   ` law
2003-05-12 16:20     ` Michael Matz
2003-05-12 17:39 ` law [this message]
2003-05-12 20:15   ` Richard Henderson
  -- strict thread matches above, loose matches on Subject: below --
2003-05-12 16:25 Richard Kenner
2003-05-12 11:37 Robert Dewar
2003-05-12 11:36 Robert Dewar
2003-05-12 11:16 Richard Kenner
2003-05-11 19:58 Richard Kenner
2003-05-13  5:59 ` Michael S. Zick
2003-05-10 18:08 Richard Kenner
2003-05-10 17:04 Richard Kenner
2003-05-10 17:18 ` Zdenek Dvorak
2003-05-10 16:49 Richard Kenner
2003-05-11 19:42 ` Kai Henningsen
2003-05-10 15:29 Richard Kenner
2003-05-10 15:52 ` Zdenek Dvorak
2003-05-10 16:09   ` David Edelsohn
2003-05-10 16:17     ` Zdenek Dvorak
2003-05-10 16:57     ` Michael S. Zick
2003-05-12  9:07   ` Richard Earnshaw
2003-05-09 23:13 Richard Kenner
2003-05-09 23:23 ` Jan Hubicka
2003-05-09 22:51 Richard Kenner
2003-05-09 22:59 ` Jan Hubicka
2003-05-09 22:30 Richard Kenner
2003-05-09 22:51 ` Jan Hubicka
2003-05-09 22:26 Richard Kenner
2003-05-09 22:44 ` Jan Hubicka
2003-05-09 22:48 ` Joe Buck
2003-05-10 12:07 ` Richard Earnshaw
2003-05-09 22:17 Richard Kenner
2003-05-09 22:24 ` Jan Hubicka
2003-05-09 21:36 Richard Kenner
2003-05-09 22:19 ` Jan Hubicka
2003-05-09 16:39 Benjamin Kosnik
2003-05-09 18:22 ` Phil Edwards
2003-05-09 16:18 Richard Kenner
2003-05-09 22:06 ` Jan Hubicka
2003-05-09 16:08 Richard Kenner
2003-05-09 21:04 ` Richard Henderson
2003-05-09 15:36 Richard Kenner
2003-05-09 15:56 ` Daniel Jacobowitz
2003-05-09 15:57 ` Michael Matz
2003-05-09 16:34   ` David Edelsohn
2003-05-09 22:01   ` Jan Hubicka
2003-05-09 14:10 Richard Kenner
2003-05-09 14:37 ` Michael Matz
2003-05-09 14:01 Richard Kenner
2003-05-09 12:12 Richard Kenner
2003-05-09 12:41 ` Michael Matz
2003-05-09 13:25 ` Paul Koning
2003-05-09 17:23 ` Joseph S. Myers
2003-05-09 20:30 ` Scott Robert Ladd

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=200305121736.h4CHa8CZ016317@speedy.slc.redhat.com \
    --to=law@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jh@suse.cz \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /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).