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: matz@suse.de, gcc@gcc.gnu.org
Subject: Re: An issue for the SC: horrible documentation quality of GCC
Date: Fri, 09 May 2003 22:06:00 -0000	[thread overview]
Message-ID: <20030509220634.GB11041@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <10305091622.AA15829@vlsi1.ultra.nyu.edu>

>     Well, when dead code is removed this will look like:
> 
>       p2 <-- 100 + p3
> 
> Only if p1 is, in fact, dead.
> 
>     But this needs to be determined at a later point, instead of cluttering
>     all the optimization passes with machine dependend checks.
> 
> You lost me here.  All of RTL and every choice within it is implicitly
> machine-dependent.  Every cost calculation is machine-dependent.  The
> entire RTL optimization strategy is based on making machine-dependent
> decisions (of course, written in machine-independent ways).
> 
>     CSE as we implement it is fundamentally different from gcse.  For one
>     our CSE is not any CSE but a kind of ad hoc value numbering
>     intertwined with expression simplification.
> 
> Again, you lost me.  It eliminates common subexpressions.  Isn't that what
> "cse" stands for?
No, the CSE algorithm as usually defined in the books would simplify
for instance:
(set (reg a) (plus b c))
(use a)
(set (reg a) (something else))
(set (reg b) (plus b c))

But our alrgorithm won't, but it would do different things CSE described
in the books won't, so it is not CSE as rest of the world know it and
naming it CSE is missleading.

Honza
> 
>     And I can't find a function in cse.c which does something similar
>     (i.e. just propagating constants and copies).  
> 
> Well, fold_rtx, I suppose, but that's because it does everything at
> one time.  And, as I've pointed out, it's not always better to
> substitute a constant for a register: sometimes, it's best to do it
> the other way around.  I have a favorite example for this:  the (non-obsolete)
> ROMP chip had an ABI where the return register and the first argument 
> register were the same. It also had a conditional return insn.  So if you
> have a function with one operand, say X, and you have:
> 
> 	if (x == 0)
> 	  return 0;
> 
> What you really want to do with the insn setting the return value is
> to change *from* the 0 *to* the equivalent, X.  That way that insn is a
> no-op, and you can do this as a conditional return insn.
> 
> CSE gets this right because it uses the cost metric.  It sounds like the
> code in gcse.c will get this wrong.
> 
>     Like I said, local_cprop* has nothing to do with gcse itself, except being
>     run to clean up the code between the gcse iterations.
> 
> Then that's all the *more* reason why it should be documented!

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

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-09 16:18 Richard Kenner
2003-05-09 22:06 ` 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 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: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=20030509220634.GB11041@atrey.karlin.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    --cc=matz@suse.de \
    /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).