Re: Inlining functions with loops

ok@cs.rmit.edu.au (Richard A. O'Keefe)
9 Dec 1995 19:45:05 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: Inlining functions with loops jeremy@suede.sw.oz.au (1995-12-01)
Inlining functions with loops dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-12-01)
Re: Inlining functions with loops serrano@ardeche.IRO.UMontreal.CA (1995-12-01)
Re: Inlining functions with loops tore@lis.pitt.edu (1995-12-09)
Re: Inlining functions with loops preston@tera.com (1995-12-09)
Re: Inlining functions with loops ball@Eng.Sun.COM (1995-12-09)
Re: Inlining functions with loops ok@cs.rmit.edu.au (1995-12-09)
Re: Inlining functions with loops jsa@organon.com (1995-12-09)
Re: Inlining functions with loops cdg@nullstone.com (1995-12-17)
| List of all articles for this month |

From: ok@cs.rmit.edu.au (Richard A. O'Keefe)
Newsgroups: comp.compilers
Date: 9 Dec 1995 19:45:05 -0500
Organization: Comp Sci, RMIT, Melbourne, Australia
References: 95-11-241
Keywords: optimize, C++

"Michael Rice" <mpr@absoft.com> writes:
>I believe the basic problem is the inability to convert such a function
>to a suitable expression tree. That is, loops are syntactically statements
>with no equivalent expression-like construct.


This has never been a problem for Lisp/Scheme inliners. There is no
reason whatsoever why expression trees cannot represent loops.


>What other languages allow inlining functions, and what constructs
>make the function un-inlinable in these languages?


Lisp, and many Scheme implementations, allow inlining. (In Scheme,
use define-integrable.) These languages treat procedure identifiers
as initialised variables, so the inliner needs some form of assurance
that these variables will not be changed. That's about it.


IBM PL/I for OS/2 supports inlining. The manual says
Some procedures and begin-blocks will never be inlined.
These include, but are not limited to:
* Procedures and begin-blocks in packages in which condition
enablement varies [basically because exception handling is
related to block activation]
* Procedures and begin-blocks containing ON or REVERT statements
[again, this is related to exception handling]
* Procedures and begin-blocks containing data-directed input/
output statements (this is like Fortran NAMELIST i/o and has to
do with keeping a symbol table of variables; inlining tends to
involve renaming, which interferes with this. It's a solvable
problem but probably not worth worrying about.)
* Procedures and begin-blocks containing assignments to or
comparisons of ENTRY, FORMAT, or LABEL constants. [These things
are attached to particular activations; there is no analogue in C++]


Loops are *not* included in this list!


Ada 83 and Ada 95 have 'pragma inline'. All the standard says is "for
each such call [to an inlined subprogram] the compiler is free to
follow or to ignore the recommendation expressed by the pragma". Ada
programmers would be surprised if the presence of loops were a reason
for ignoring 'inline'.


>I suppose some pseudo-expression for loops could be created to handle
>this.


>I also have to wonder if this is worth the work. Any comments?


If you have a good abstract tree representation, it _isn't_ any extra
work. In Scheme, a loop can appear anywhere a function call can,
whether there is an inline expansion or not, so a compiler has to be
able to deal with it.


--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.