From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7297 invoked by alias); 9 May 2003 22:17:27 -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 7286 invoked from network); 9 May 2003 22:17:27 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 9 May 2003 22:17:27 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA19835; Fri, 9 May 03 18:22:08 EDT Date: Fri, 09 May 2003 22:17:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10305092222.AA19835@vlsi1.ultra.nyu.edu> To: jh@suse.cz Subject: Re: An issue for the SC: horrible documentation quality of GCC Cc: gcc@gcc.gnu.org X-SW-Source: 2003-05/txt/msg00956.txt.bz2 No, the CSE algorithm as usually defined in the books would simplify for instance: (set (reg a) (plus b c)) (use a) (set (reg a) (something else)) (set (reg b) (plus b c)) But our alrgorithm won't, but it would do different things CSE described in the books won't, so it is not CSE as rest of the world know it and naming it CSE is missleading. Well I'm not sure what the "usual" cse algorithm would simplify this into since the result of the addition is no longer around, but defining an algorithm by what it would do in an obscure case seems odd to me.