From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22004 invoked by alias); 13 Aug 2005 23:07:24 -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 21507 invoked by uid 22791); 13 Aug 2005 23:07:19 -0000 Received: from postfix4-2.free.fr (HELO postfix4-2.free.fr) (213.228.0.176) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 13 Aug 2005 23:07:19 +0000 Received: from napoca.cri.ensmp.fr (lns-vlq-41-str-82-252-43-59.adsl.proxad.net [82.252.43.59]) by postfix4-2.free.fr (Postfix) with ESMTP id D1D261C679B; Sun, 14 Aug 2005 01:07:16 +0200 (CEST) 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 j7DNC9YQ007765; Sun, 14 Aug 2005 01:12:10 +0200 Received: (from seb@localhost) by napoca.cri.ensmp.fr (8.13.3/8.13.3/Submit) id j7DNC9Pn007762; Sun, 14 Aug 2005 01:12:09 +0200 Date: Sat, 13 Aug 2005 23:07:00 -0000 From: Sebastian Pop To: Joe Buck Cc: Dan Kegel , GCC Mailing List Subject: Re: [GCC 4.2 Project] Omega data dependence test Message-ID: <20050813231208.GA7617@napoca.Belkin> References: <42F77CFF.6040606@kegel.com> <20050808183531.GA324@napoca.cri.ensmp.fr> <20050808224649.GA11610@synopsys.com> <20050809145928.GA4156@napoca.cri.ensmp.fr> <20050809162344.GB11610@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050809162344.GB11610@synopsys.com> User-Agent: Mutt/1.5.6i X-SW-Source: 2005-08/txt/msg00399.txt.bz2 Joe Buck wrote: > The problem with using time as a cutoff is that you then get results that > can't be reproduced reliably. Better to count something that is a feature > of the algorithm, e.g. number of executions of some inner loop, number of > nodes visited, or the like, On the other hand, it is not based on such features that you'll be able to provide a watermark on time and space... Having guarantees on compile time and space is probably what some users will want instead of yet another bunch of --param max-foo-nodes. I'd like to ask GCC users in general: how many are using these params? Why not having instead a set of flags that limit the resources allowed for each "unnecessary" (to be defined...) part of the compiler? For example, I'd like a guarantee that any tree level optimizer will stop after at most 5 seconds and at most 300M of garbage: you'd say, -fbudget-time=5 and -fbudget-space=300M instead of having to deal with some obscure params. > so that all users get the same results. I see your point: we'll have bug reports that will be difficult to reproduce. I have not yet thought at a solution for this one, but there should be some practical way to make bugs deterministic again, otherwise we'll just step into a Schrodinger box, and that's a Bad Thing. seb