From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11456 invoked by alias); 8 Aug 2005 18:31:12 -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 11404 invoked by uid 22791); 8 Aug 2005 18:31:02 -0000 Received: from orgenoy.ensmp.fr (HELO cri.ensmp.fr) (193.48.171.195) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 08 Aug 2005 18:31:02 +0000 Received: from napoca.cri.ensmp.fr (napoca.cri.ensmp.fr [10.2.14.221]) by cri.ensmp.fr (8.11.2/8.11.2/mx-cri-CRI) with ESMTP id j78IUqf06751; Mon, 8 Aug 2005 20:30:53 +0200 (MEST) Received: from napoca.cri.ensmp.fr (localhost [127.0.0.1]) by napoca.cri.ensmp.fr (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id j78IZWKf002649; Mon, 8 Aug 2005 20:35:34 +0200 Received: (from seb@localhost) by napoca.cri.ensmp.fr (8.13.3/8.13.3/Submit) id j78IZWMS002646; Mon, 8 Aug 2005 20:35:32 +0200 Date: Mon, 08 Aug 2005 18:31:00 -0000 From: Sebastian Pop To: Dan Kegel Cc: GCC Mailing List Subject: Re: [GCC 4.2 Project] Omega data dependence test Message-ID: <20050808183531.GA324@napoca.cri.ensmp.fr> References: <42F77CFF.6040606@kegel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F77CFF.6040606@kegel.com> User-Agent: Mutt/1.5.6i X-SW-Source: 2005-08/txt/msg00235.txt.bz2 Dan Kegel wrote: > Sebastian Pop wrote: > > [http://gcc.gnu.org/wiki/Omega%20data%20dependence%20test] > > ... > I can't understand a word of the proposal. > Mabe you were trying to be funny, but it ended up being obscure. I'm sorry. This was not my intent. > If the average gcc developer can understand it, then > it doesn't matter that I can't, but I have a feeling > others might find it hard to read, too. > I'll try to explain again the goal of the project in a shorter version. I have implemented a data dependence analysis, and I want to validate the results that it produces. For this, I'm proposing to compute the same information using another algorithm, and finally do a diff. The second implementation of the data dependence analysis is using the Omega solver. However, this solver is known to be exponential on some cases (not all the cases, and in practice when used for basic data dependence problems it is fast). So the only option we have is to not expose this solver to our users, but use it for debugging and improving the compiler. This was also the purpose of the long term "plans": we can use this kind of expensive yet exact analyzers to detect deficiencies in the compiler, and report bugs. > But this part caught my eye: > > > In a further future, when GCC will finally have a proper > > intermediate representation that can be stored to disk and then > > loaded back to memory, we will transform the SEB into GCC > > contributors. The plan is to propose the integration of a delta > > debugger (DD) into GCC such that the regression flags will directly > > output a reduced pattern that will show the regression. A > > pattern-zilla will collect the optimal solution and a testcase that > > show the weakness of a heuristic function. > > Since I started playing with delta debugging for > tracking down ICEs, I've been thinking it might > be nice to have an option to gcc to perform > delta debugging automatically if an ICE occurs, > and have it automatically submit the minimized > testcase. Exactly. For example, it will be possible to replace the fancy_abort with a DD. Another thing that users of the compiler want is an automatic variable renaming, such that the testcase that they provide does not reveal parts of their projects. All these can be integrated in GCC once we have this intermediate representation dump to disk. > Sounds like you're talking about something > similar, but not for ICEs. I wish I understood your > proposal better. As Daniel Berlin has pointed out, a smarter DD can be implemented directly in the compiler. What is guiding the current DDs is a fail to a test: the ICE. The same thing can be implemented in the compiler, and you can have as an objective to minimize the size of the representation while still preserving a feature of the original program. This feature can be, for example, a regression with respect to an optimal solution. So clearly you have two paths for detecting regressions: either you evaluate a run of the produced code on some machine and for a given input data (something like Anthony's regression hunting), or you attack the results of the heuristic functions with an exact solver, as written by Mark in the oracular optimization page. Sebastian