public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: mustafa@il.ibm.com, vmakarov@redhat.com
Cc: zaks@il.ibm.com, gcc mailing list <gcc@gcc.gnu.org>,
	David Edelsohn <dje@watson.ibm.com>
Subject: Re: DDG - Implementing Swing Modulo Scheduling in GCC (cont.)
Date: Fri, 12 Dec 2003 02:36:00 -0000	[thread overview]
Message-ID: <8327FE12-2C4B-11D8-8CD9-000A95DA505C@dberlin.org> (raw)


> So in general the data design looks ok to me of course if it is enough
> for your implementation of SMS.  I've found some simplifications in 
> data
> analysis.  You are searching dependencies between iterations with only
> the distance equal to 1.  It is better to use a general framework
> dependence.c (now it is not a part of gcc mainline because it is not
> used by any part of gcc) written by Stan Cox.  If it is hard to
> understand or support this, you could implement at least the same
> functionality.

I *strongly* recommend against reviving dependence.c, for the following 
reasons:
1. As submitted, it didn't work (it required some modifications and 
hooks into the c front end that were never committed/approved).
2. What did "work" (ie when you put in the right hooks) was buggy and 
often segfaulted (i tried to use it for something for about a week or 
two before giving up because it kept segfaulting on trivial code).
3. It constructs it's own def-use chains from trees
4. It tries to do dependence on our arbitrarily complex tree structure


3 and 4 are artifacts of trying to do dependence without tree-ssa.
Most of the code in dependence.c was dealing with these def-use chains, 
so you'd be better off not using it as a starting point.

If you must have better tree->rtl dependence info passed down (which is 
what dependence.c did), i'd suggest starting with Sebastian Pop's 
recently posted work, and having the results passed down to the RTL 
level somewhat like dependence.c does.

Though starting with some simple RTL dependence and then using more 
advanced tree dependence info passed down to RTL when tree-ssa arrives 
sounds like a good option.
--Dan

             reply	other threads:[~2003-12-12  2:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-12  2:36 Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-12-12 20:00 Ayal Zaks
2003-12-11 16:59 Ayal Zaks
2003-12-10 17:03 Mostafa Hagog
2003-12-11  5:12 ` Richard Henderson
2003-12-11  7:43   ` David Edelsohn
2003-12-11 17:02 ` Vladimir Makarov

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=8327FE12-2C4B-11D8-8CD9-000A95DA505C@dberlin.org \
    --to=dberlin@dberlin.org \
    --cc=dje@watson.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mustafa@il.ibm.com \
    --cc=vmakarov@redhat.com \
    --cc=zaks@il.ibm.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).