From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5262 invoked by alias); 25 May 2007 13:46:14 -0000 Received: (qmail 5131 invoked by uid 22791); 25 May 2007 13:45:58 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 May 2007 13:45:51 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4PDjnGE020997; Fri, 25 May 2007 09:45:49 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4PDjmxk021105; Fri, 25 May 2007 09:45:48 -0400 Received: from [10.13.248.28] (vpn-248-28.boston.redhat.com [10.13.248.28]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l4PDjls1012498; Fri, 25 May 2007 09:45:47 -0400 Message-ID: <4656F755.3000702@redhat.com> Date: Fri, 25 May 2007 13:50:00 -0000 From: "Vladimir N. Makarov" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 MIME-Version: 1.0 To: Steven Bosscher CC: gcc-patches Subject: Re: dataflow branch merging plans. References: <46543F49.8060104@naturalbridge.com> <46557380.9060105@t-online.de> <571f6b510705241344u750c6499r27942cda78f40e32@mail.gmail.com> <46562C36.5090605@redhat.com> <571f6b510705241552x2b8665ffre1f691aeeaee982@mail.gmail.com> In-Reply-To: <571f6b510705241552x2b8665ffre1f691aeeaee982@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg01716.txt.bz2 Steven Bosscher wrote: > On 5/25/07, Vladimir N. Makarov wrote: > >> Steven, I really value your help in rewriting old pipileine descriptions >> to the DFA ones but please be more accurate when you jump the >> conclusion like "the DFA for Itanium is the problem here" or saying on >> IRC that most interesting work on the DFA was done by Zack. That is not >> true. > > > I never said there is anything wrong with the DFA approach to > scheduling. All I said is that the compile time bottleneck for Itanium > is the DFA for itanium, i.e. the automaton that's generated from the > MD files in config/ia64/. They're huge, and they probably have to be > given the complexity of the architecture, but it makes the whole thing > slow enough to be consistent top hits on the profiles. > > I also seem to recall I said that Zack has done all the good work on > genautomata, and I think it's pretty much generally agreed that the > algorithms you originally used to implement genautomata left some > rather large room for improvement. > What you wrote was: honza: you know vlad... he has great ideas, in theory, but there's a reason why he never manages to actually finish something properly ;-) hmm, for example dfa automatos does their job relatively well... ...if you're willing to accept that: a) it takes 30% of the total compile time b) all the good parts are written by zack c) all the scheduler descriptions except itanium are written by me (oh, and mips, which paolo bonzini took care of) wrt. a, that's on itanium SPEC. Well a) is not true. Probably 30% is true for all scheduler and the DFA takes about 2-3% as I remember profile for combine.i. Slow insn scheduler is Itanium specific. Intel even designed and patented path based data dependence representation to speed up their wavefront-scheduler. I read b) as I wrote bad parts. The most interesting part what Zack changed in the DFA is 4KB savings in generated tables. I don't know why you mentioned Zack, there were many contributors to genautomata.c. May be you meant something else. Then I am sorry for misunderstanding. Therefore I asked you to be more accurate. As for your the very first remark above, that is your typical generalization. I managed to write many things. The last big ones were an optimizing cross-compiler of an extendend Pascal for one american company (I wrote all the compiler except tests. That was about 100K lines of C) and ongoing project cocom (cocom.sf.net) for which sloccount gives Total Physical Source Lines of Code (SLOC) = 218,688 Development Effort Estimate, Person-Years (Person-Months) = 57.26 (687.11) > The only one jumping to conclusions here is you, twisting my words > somehow in ways to make them offending to you. That is your problem, > not mine. Sory if I am twisting your words but I feel offended by your remarks on IRC about me like "vlad's_latest_doomed_before_started_project" about my register allocator project (by the way I am planning to put IRA to gcc-4.4) or about my style of work. You know I think I am not alone: if collect your remarks on IRC about other people, probably it would be not a great portrait.