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
next 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).