From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19448 invoked by alias); 24 Feb 2003 02:48:33 -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 19441 invoked from network); 24 Feb 2003 02:48:33 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by 172.16.49.205 with SMTP; 24 Feb 2003 02:48:33 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 0CEE1F2E4C; Sun, 23 Feb 2003 21:48:33 -0500 (EST) To: dewar@gnat.com, rmyers1400@attbi.com Subject: Re: Feedback-driven optimization Cc: gcc@gcc.gnu.org, jh@suse.cz, rth@redhat.com Message-Id: <20030224024833.0CEE1F2E4C@nile.gnat.com> Date: Mon, 24 Feb 2003 05:06:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-02/txt/msg01571.txt.bz2 > There's alot to read, and I've scanned a fair bit of it. No one seems > to have tried anything as ambitious as what I have in mind, which, is > given all the preconceptions and experience available, come up with a > best expected strategy. There are fairly straightforward recipes for > doing this, but I don't think anybody has actually tried them. What > people *have* done is to use profiling to identify areas for increased > scrutiny, but with only limited success. That's very far from true, and indicates that you should do a bit more "scanning". Have you read for example the basic work on trace scheduling (and in particular the Multiflow technology -- there was a reason that Intel paid millions of dollars for access to this technology!)