Re: Pragma Inline and its Effects of Compilation Dependencies.

[Robert Dewar <dewar@gnat.com>]

In article <8b64ul$jov$1@inputplus.demon.co.uk>,
  ralph@inputplus.demon.co.uk (Ralph Corderoy) wrote:

> I was recently asked to look into an Ada compilation problem
> that centred around the use of pragma inline.  The result was
> a realisation that the pragmas weren't accurately reflected in
> the compiler suite's dependency graph used to determine
> compilation order.  Consequently, when building a set of
> source from scratch a separate containing an
> inlined routine wasn't being built before its callers.
>
> I'd like to check that I understand what's wrong and how it
> should work, and then ask for advice on where to go from here.

Your Ada compiler is being unfriendly, but not inaccurate, i.e.
the reference manual certainly permits the behavior you see. It
is quite legitimate for a compiler to fail to inline something
because the right body has not been compiled yet. The use of
pragma Inline does create additional dependencies *if* the
procedure is inlined, but there is no guarantee that the
inlining will occur.

In systems where compilation order is important (unlike GNAT
where this issue does not arise), the user is responsible for
manually choosing the order of compilation that optimizes the
use of inlining.

Consider the following:

  package x is
     procedure xx ...
     pragma Inline (xx);
     ...
  end x;

  with y;
  package body x is
      ...
      y.yy;
  end x;

  package y is
     procedure yy ...
     pragma Inline (yy);
     ...
  end y;

  with x;
  package body y is
     ...
     x.xx;
  end y;

Now in a compiler with a conventional Ada 83 style library,
the rule is that you can only inline the call y.yy if the
body of y is compiled before the body of x, and you can
only inline the call x.xx if the body of x is compiled before
the body of y.

Since both of those cannot be true, only one of these calls
can be inlined. The additional dependency will be created for
the one that is inlined, assuring consistency, but one of the
inlines will not happen.

The only way to avoid this if you have a conventional Ada 83
style library is to do inlining at the binder stage, but this
is quite expensive (I think the old Telesoft compiler did this).
Certainly the old Alsys compiler had the behavior described
above.

This often causes surprises, and means that order of compilation
is crucial in such systems and must be worked out very
carefully. Obviously no tool can do a fully automatic job, since
in the above example, both requirements cannot be met, and it
requires intervention to specify which of the two inlinings is
more important.

One of the big advantages of the source based model used first
by GNAT, and later by some (but not all) other Ada 95 compilers
is that inlining can be done accurately. In the case of GNAT
for example, the use of gnatmake with the -gnatn switch to turn
on inlining will guarantee that ALL specified inlining is
properly processed, and as usual the order of compilation is
completely irrelevant (both inlinings will be handled properly
in the above example regardless of the order of compilation).
In GNAT, it is an absolute guarantee that the order in which
compilations are done has no effect whatever on the generated
code.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.