From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19965 invoked by alias); 9 May 2003 16:08:54 -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 19925 invoked from network); 9 May 2003 16:08:54 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 9 May 2003 16:08:54 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA15763; Fri, 9 May 03 12:13:34 EDT Date: Fri, 09 May 2003 16:08:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10305091613.AA15763@vlsi1.ultra.nyu.edu> To: drow@mvista.com Subject: Re: An issue for the SC: horrible documentation quality of GCC Cc: gcc@gcc.gnu.org X-SW-Source: 2003-05/txt/msg00907.txt.bz2 We don't live in a void of one flat source tree. While I'm not arguing that documentation would be better, it's still easy to find the history of this code. It was added last July by Jan, in this patch: http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00617.html Indeed now that I see that message, I remember it. But it doesn't answer the question I have: why is it appropriate to have *two* constant propagation routines within a basic block where only one (the one in cse.c) knows how to properly apply cost functions? At the time I saw this message, I was dubious about this and thought I even raised the issue on the lists. Moreover, this goes counter to the claim that was made just a few hours ago, which is that the "local" did *not* refer to doing something that was non-global, thus showing that there is indeed major confusion due to lack of documentation. However, the patch as cited in the message should *not* have been approved, both because of the missing documentation, and because of the confusion about the role of CSE in this task, as exemplified by the last sentence of the posting: "I am surprised our local CSE don't know how to handle it, but I will check it separately." Since that "check" should have resulted in not needing this patch, it needed to be done before the patch was approved. My point in raising this was not to specifically get the information on the code (as you point out, it's not hard to find the message where a particular piece of code was first proposed), but to address the more general issue that there are *lots* of code that are improperly documented and it's unreasonable to do this sort of search for *every* such function.