From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16120 invoked by alias); 12 Dec 2003 02:33:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16113 invoked from network); 12 Dec 2003 02:33:11 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 12 Dec 2003 02:33:11 -0000 Received: from [192.168.1.7] (account dberlin [192.168.1.7] verified) by dberlin.org (CommuniGate Pro SMTP 4.1.4) with ESMTP-TLS id 5654139; Thu, 11 Dec 2003 21:33:09 -0500 Mime-Version: 1.0 (Apple Message framework v608) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8327FE12-2C4B-11D8-8CD9-000A95DA505C@dberlin.org> Content-Transfer-Encoding: 7bit Cc: zaks@il.ibm.com, gcc mailing list , David Edelsohn From: Daniel Berlin Subject: Re: DDG - Implementing Swing Modulo Scheduling in GCC (cont.) Date: Fri, 12 Dec 2003 02:36:00 -0000 To: mustafa@il.ibm.com, vmakarov@redhat.com X-SW-Source: 2003-12/txt/msg00686.txt.bz2 > 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