Re: When to do inline expansion

zstern@adobe.com (Zalman Stern) writes:
>If it is called precisely once in the program, the function should be
>inlined no matter what.


jfc@athena.mit.edu (John F Carr) writes:
I disagree. Some cases where inlining may hurt:


    . the inlined function is so complex that it needs more registers
    than are available at the point of inlining


Mary Hall (now at Stanford) did an extensive study on the costs of
inlining in Fortran routines. She inlined over 99% of the dynamic calls
with reasonable code size growth. She found it was a net "no-gainer" for
speed.


Pros: Better local analysis, no subroutine call/return overhead


Cons: Many commercial compilers did lousy jobs of optimization on giant
            procedures. Register allocators seemed to suffer a lot (no Sparc
            compiler I know of will use a window push/pop in the middle of a
            routine to spill registers). Call sites are a way for the
            programmer to tell the compiler: "Spill here".


            Fortran subroutine calls have *extra* semantic information: all arrays
            passed are guarenteed not to be aliased. This let the MIPS compiler
            get the kernal of (DAXPY? some linpack kernal) right. When inlined the
            same code ran much slower because the compiler inserted stalls under
            the assumption that the arrays might be aliased.


            At least one compiler was using an exponential algorithm; compile
            time went from minutes to *days*.


All of these problems can be fixed (may already be fixed!), but only
experimentation on new compilers will tell.


Mary found that selective inlining (cloning) to be beneficial. Read her
papers for details. One idea: you clone when you can arrange for several
call sites to pass identical constants to the cloned procedure.




@phdthesis{Hall:Thesis,
    author={Mary W. Hall}, title={Managing Interprocedural Optimization},
    school={Rice University}, month=April, year=1991, location=31}


@article{cooper:92,
    title="Unexpected Side Effects of Inline Substitution: A Case Study",
    author="Keith D. Cooper and Mary W. Hall and Linda Torczon",
    pages="22--32", journal=loplas, year=1992, month=mar, volume=1, number=1}


@inproceedings{chk:92,
    title="Procedure Cloning",
    author="Keith D. Cooper and Mary W. Hall and Ken Kennedy",
    booktitle="Proceedings of the IEEE Computer Society 1992
                International Conference on Computer Languages",
    year=1992, month=apr, pages="96--105", file=79}


@article{cht:91,
    title="An Experiment With Inline Substitution",
    author="Keith D. Cooper and Mary W. Hall and Linda Torczon", journal=spe,
    year=1991, month=jun, volume=21, number=6, pages="581--601", file=77 }




Cliff
--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
[Loss of aliasing info is the best known ``gotcha'' in Fortran (and, probably
any) in-lining. Does anyone know of real compilers where they correctly
track the unaliasable variables in inlined Fortran? -John]
--

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