Re: GNAT and register allocation

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 21.04.12 14:10, Stephen Leake wrote:

>> I must use one set of options for an entire program in this case.
>
> Why?

This requirement is likely a fact (external) that we can't change.
We may try one day.

> gpr files give you a way to apply different compilation options to
> different files. There are _lots_ of low-level gcc options controlling
> inline and other optimizations; see gnat user guide, section 3.10.

Controlling inline expansion with GCC's -f[no]-inline[-*] can
require that the entire program be reorganized. Consider a call chain:

A
-> B
--> C
---> D

I want to specify that D be expanded inline into C,
but also want to prevent C from being expanded into B.
That is, B should actually call C. Right now, the bodies
of B, C, and D are neighbors in the same scope.

In this case, a possible solution seems to be to arrange
for separate compilation units. Specify -fno-inline-functions
for the translation of B, and enable inline expansion for C and D.
Is this correct? OR will the "outer" inline prevention override
the "inner"?

I'm also no sure yet whether or not this arrangement will be possible
using Ada's feature for separate compilation ("separate" keyword),
or whether I would have to make a child package containing C and D.
(IIRC, GNAT uses slightly different rules for subprograms declared
separate in other subprograms than for subprograms declared separate
in (non-generic?) packages.)

If this procedure adequately describes how to achieve inline control,
then I will find a compiler pragma a little easier.