Re: Pragma Inline and its Effects of Compilation Dependencies.

[ralph@inputplus.demon.co.uk (Ralph Corderoy)]

Hi Robert,

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

Yes, I'm happy that `pragma inline' is merely a request, and the
compiler we're using gives a warning when the routine can't be inlined
because it hasn't been compiled yet.  I should have been a little more
explicit;  one of the programs that comes with the compiler is meant to
examine a bunch of source and produce a linear order for compilation.
That program creates a dependency from the caller to the body of the
package containing the inlined routine, even when the routine is in a
separate.

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

Agreed, except that the compiler comes with this program to ease our
manual burden.  It looks like we're stuck maintaining a manual order
for now.

> Consider the following:
> 
> [snip cyclic dependency example]
> 
> 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.

Yep, I'm happy with that too;  if our source has a cycle then we'd be
quite happy to either break it by removing a pragma inline or moving
source around, or specify to the program which inline is more
important.

The current problem we're having doesn't involve any cycles.

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

Is there a diagram anywhere showing the various Ada compilers and their
lineage, if any?

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

In our case, it does seem that a tool could do a more correct
automatic job than it is currently doing.

> In GNAT, it is an absolute guarantee that the order in which
> compilations are done has no effect whatever on the generated code.

Yes, I agree it seems great (having never used it).  Must have been
strange at the time to go against the accepted wisdom and always refer
back to all the sources.

Thanks for the detailed response.


Ralph.