From owner-sc22wg5@dkuug.dk Fri Oct 10 20:09:47 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id h9AI9lxI050175 for sc22wg5-domo; Fri, 10 Oct 2003 20:09:47 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id h9AI9dEt050170 for ; Fri, 10 Oct 2003 20:09:42 +0200 (CEST) (envelope-from vsnyder@mls.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.8/8.12.8) with ESMTP id h9AI9xAQ014755 for ; Fri, 10 Oct 2003 11:09:59 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h9AI9xso014751 for ; Fri, 10 Oct 2003 11:09:59 -0700 Message-Id: <200310101809.h9AI9xso014751@math.jpl.nasa.gov> X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 To: sc22wg5@dkuug.dk Reply-to: Van.Snyder@jpl.nasa.gov Subject: Re: (SC22WG5.3030) INLINING In-Reply-To: Your message of "Fri, 10 Oct 2003 17:20:24 BST." <200310101620.h9AGKPuG048210@dkuug.dk> From: Van.Snyder@jpl.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Oct 2003 11:09:59 -0700 X-Spam-Score: 0.339 () NO_REAL_NAME Sender: owner-sc22wg5@dkuug.dk Precedence: bulk On Fri, 10 Oct 2003 17:20:24 BST J.L.Schonfelder" wrote: > An instruction to INLINE appears to me on a par with an instruction to > optimise, say, by removing constant loop independent expressions. It is not > a language issue. The language may be phrased so that all the information > required for the processor to determine that it would be safe to inline but > is then a quality of implementation issue whether inlining is performed. The issue isn't whether it's safe to inline, it's whether it would be productive to do so. And deciding whether it's productive to inline is a very different problem from hoisting loop-constant subexpressions. Some processors allow users to feed back profile information, which the processor then uses in decisions whether to inline. For users of processors that don't provide such a nice automatic tool, users could still benefit from feeding back profile information, in the form of an attribute or directive. In the same spirit that processors use profile information as advice, not compulsion, I proposed that the INLINE attribute is advice to the processor, not an instruction to the processor. I discovered the advantage of inlining one subprogram by using a profiler. Of the compilers I use, only one provides for profiling, and it doesn't provide for global compilation or use of fed-back profiling information for optimization. Inlining by hand was tedious, and -- as I reported -- prone to errors. Automatic inlining, perhaps based on automatic feedback of profile information, would be best. Some standard mechanism to give advice to the processor would be more useful than no mechanism at all. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.