Re: Inlining functions with loops

cdg@nullstone.com (Christopher Glaeser)
Fri, 1 Dec 1995 07:42:11 GMT

          From comp.compilers

Related articles
Inlining functions with loops mpr@absoft.com (Michael Rice) (1995-11-29)
Re: Inlining functions with loops jplevyak@violet-femmes.cs.uiuc.edu (1995-11-30)
Re: Inlining functions with loops meissner@cygnus.com (Michael Meissner) (1995-11-30)
Re: Inlining functions with loops preston@tera.com (1995-11-30)
Re: Inlining functions with loops ayers@apollo.hp.com (1995-11-30)
Re: Inlining functions with loops cdg@nullstone.com (1995-12-01)
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)
[3 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: cdg@nullstone.com (Christopher Glaeser)
Keywords: optimize, C++
Organization: Compilers Central
References: 95-11-241
Date: Fri, 1 Dec 1995 07:42:11 GMT

Michael Rice <mpr@absoft.com> writes:
> Is anyone aware of a compiler for any language which is
> able to do this? [... inline functions with any type of loop ...]


Yes, some C compilers will inline functions with FOR loops. In addition,
recursion is a type of loop, and some C compilers will inline recursive
functions.


> 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.


Based upon black-box performance analysis of a quite a few compilers, I don't
think expression tree representation is always the limiting factor. Inline
expansion can often (but not always) result in increased code size, and can
sometimes result in less performance. Embedded compilers are particularly
sensitive to code size issues. So, compilers often use hueristics to control
which fuctions are expanded inline, such as number of *nodes* within the
function to be inlined.


> For example: if(c1) e1 else e2 can be converted to c1 ? e1 : e2
> e1; e2; e3 can be converted to e1,e2,e3


While this transformation is possible, most C compilers will perform the
reverse transformation in the parser (i.e. translate ?: into if-then-else),
and few optimizers can reverse this transformation. For example, many
compilers can hoist the loop invariant expression (a + b) out of a loop,
but can not hoist the loop invariant expression (a ? b : c) out of a loop,
the reason being that this expression has already been translated to an
if-then-else in the parser, which is much more difficult to hoist out of
a loop.


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


If you consider tail recursion to be a loop, then, yes, the performance
improvement can be significant.


Regards,
Christopher Glaeser
Nullstone Corporation
--


Post a followup to this message

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