|[6 earlier articles]|
|Re: Inlining functions with loops email@example.com (1995-12-01)|
|Inlining functions with loops firstname.lastname@example.org (Dave Lloyd) (1995-12-01)|
|Re: Inlining functions with loops serrano@ardeche.IRO.UMontreal.CA (1995-12-01)|
|Re: Inlining functions with loops email@example.com (1995-12-09)|
|Re: Inlining functions with loops firstname.lastname@example.org (1995-12-09)|
|Re: Inlining functions with loops ball@Eng.Sun.COM (1995-12-09)|
|Re: Inlining functions with loops email@example.com (1995-12-09)|
|Re: Inlining functions with loops firstname.lastname@example.org (1995-12-09)|
|Re: Inlining functions with loops email@example.com (1995-12-17)|
|From:||firstname.lastname@example.org (Richard A. O'Keefe)|
|Date:||9 Dec 1995 19:45:05 -0500|
|Organization:||Comp Sci, RMIT, Melbourne, Australia|
"Michael Rice" <email@example.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
>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.
Return to the
Search the comp.compilers archives again.