public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
To: jh@suse.cz
Cc: gcc@gcc.gnu.org
Subject: Re: An issue for the SC: horrible documentation quality of GCC
Date: Sat, 10 May 2003 02:21:00 -0000	[thread overview]
Message-ID: <10305100225.AA20837@vlsi1.ultra.nyu.edu> (raw)

    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.

    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.

    I am still in the dark.  Perhaps it is time to go sleep first and then
    continue in arguing.  Could you give me some example of code what you
    would like to get transfromed?

It's code that I *don't* want to see transformed.  For example, if I call
a group of functions and pass each a constant of 100 on a RISC machine where
the first operand is passed in RX, I expect to see a series of insns, each
setting RX to 100.  I don't want to see one insn setting a pseudo to 100
and then insns setting RX to that.

    >     I man extended basic block like:
    > 
    >       A
    >      / \
    >     B   C
    > 
    > That's not what cse.c means by an extended basis block.

    CSE will actually follow the jumps, so it should track it.

Yes, but that's not the case I'm talking about: I'm talking about the
extended basic block ase.

It is just pure if-then-else (I didn't draw the join edge)

    How? Assuming that B has some other instructions, I will end up with
    both, the copy and the branch.  Or do I miss something else?

I think we're talking about

	if (condition)
	   A
	else
	   B

This has two jumps.

If I can make A into a NOP, this becomes

	if (!condition)
           B

which has one jump.

             reply	other threads:[~2003-05-10  2:21 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-10  2:21 Richard Kenner [this message]
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
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=10305100225.AA20837@vlsi1.ultra.nyu.edu \
    --to=kenner@vlsi1.ultra.nyu.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=jh@suse.cz \
    /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).