public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz>
To: Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
Cc: rth@redhat.com, gcc@gcc.gnu.org
Subject: Re: An issue for the SC: horrible documentation quality of GCC
Date: Fri, 09 May 2003 22:19:00 -0000	[thread overview]
Message-ID: <20030509221946.GC11041@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <10305092141.AA19446@vlsi1.ultra.nyu.edu>

>     Because cse.c is too slow.  It cannot be used for code cleanup
>     within another pass.  Compilation time being high on everyone's
>     minds, I think this is an exceedingly good reason to have two
>     passes.
> 
> Fair enough, but it would seem that all it has to do is to add a
> REG_EQUAL note to accomplish its inter-pass purposes and then let CSE
> decide whether the zero or a register is best.

This would not work for the copy propagation (as we need to remove the
reference to the register in order to get dead code removed).

For constant propagation this scheme would work I guess.  It came in
with the original gcse checkin in 97 (about the time I started to get
interested in GCC) and in fact I've added the code to add REG_EQUAL
notes in order to get it working in more complicated situations.  (where
the actual replacement is not possible - old code just gave up).  I
never tried the more radical approach of killing the replacement code
entirely. 

Can you do some benchmarking on ROMP?  I was worried about that when I
was adding the local coprop pass (that don't introduce the problem just
make it worse) and i did evaulation on SPARC (maybe MIPS, don't remember
exactly) and the code produced was faster and shorter on the average so
I concluded that this should be mostly safe.  When the constant is
expensive, it usually means that it needs to be loaded to the register
always and then the pattern should refuse immediate operand.  Perhaps
ROMP is different.
Honza

  reply	other threads:[~2003-05-09 22:19 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-09 21:36 Richard Kenner
2003-05-09 22:19 ` Jan Hubicka [this message]
  -- 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-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
2003-05-12 20:15   ` Richard Henderson
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 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=20030509221946.GC11041@atrey.karlin.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    --cc=rth@redhat.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).