From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id A0922BBAF for ; Thu, 18 May 2006 19:46:23 +0200 (CEST) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4IHkNM9002656 for ; Thu, 18 May 2006 19:46:23 +0200 Received: from [192.168.1.2] (che78-2-82-237-71-191.fbx.proxad.net [82.237.71.191]) by smtp2-g19.free.fr (Postfix) with ESMTP id 21F3673193; Thu, 18 May 2006 19:46:22 +0200 (CEST) Message-ID: <446CB2EE.1080102@inria.fr> Date: Thu, 18 May 2006 19:46:22 +0200 From: Xavier Leroy User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Carette Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] compiler bug? References: <20060517231426.30289.qmail@web32203.mail.mud.yahoo.com> <446CABCA.8000906@inria.fr> <446CB021.6000009@mcmaster.ca> In-Reply-To: <446CB021.6000009@mcmaster.ca> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 446CB2EF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; compiler:01 bug:01 solver:01 compilers:01 compiler:01 ocamlopt:01 compilers:01 compilation:01 solver:01 solvers:01 caml-list:01 integer:01 linear:02 optimizing:02 programming:03 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 >> Well, there is the paper by George and Appel where they use an ILP >> solver (integer linear programming) to produce optimal spills, but >> that's kind of expensive... > > It is my impression that users of compilers are "ready" for the > following situation: > 1) an optimizing compiler (like ocamlopt!) that produces good code > efficiently > 2) a super-optimizing compiler that produces fantastic code, at whatever > cost. Clearly, you're not the guy who would have to support both compilers :-) More seriously, I agree that optional "super-optimization" passes could be useful in some cases. Actually, George and Appel found that compilation times with their approach were almost reasonable (e.g. a few minutes instead of a few seconds for a standard compiler), but they had to use a commercial ILP solver. If only there were *really good* ILP and SAT solvers under free licenses... - Xavier Leroy