From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30924 invoked by alias); 12 May 2003 16:25:23 -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 30837 invoked from network); 12 May 2003 16:25:21 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 12 May 2003 16:25:21 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA05997; Mon, 12 May 03 12:30:05 EDT Date: Mon, 12 May 2003 16:25:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10305121630.AA05997@vlsi1.ultra.nyu.edu> To: matz@suse.de Subject: Re: An issue for the SC: horrible documentation quality of GCC Cc: gcc@gcc.gnu.org X-SW-Source: 2003-05/txt/msg01158.txt.bz2 > For this and other reasons I've come to the conclusion that we need to > separate our optimizations into generic and target dependent > optimizations. And that conceptually the generic optimizations should > strive to eliminate as much redundancy as possible, fully propagate > constants/copies, etc and leave it to the expanders and target > dependent optimizers to "undo" unprofitable redundancy elimination, > cprop, etc. Amen. And I continue to strongly disagree with the above. The key to GCC's success over the years has precisely been the knowlege of the underlying machine characteristics within the optimizers. I certainly agree that there are some high-level optimizations that can be peformed in a machine-independent manner and these are the ones that are being done on trees. But I think that once we're at the state of optimizing RTL, all optimizers need to know a lot about the machine they are optimizing for. Moreover, I believe that the RTL optimizers will always have to have duplicate optimizations with the tree level: for example, address calculations can produce common subexpressions (often global) and loop invariants.