GNAT and register allocation

GNAT and register allocation

[Georg Bauhaus]

Hi,

in short, is there anything that one can do to make
GNAT use many registers? MMX registers in particular,
but not only.

It appears that the number of registers allocated increases
with inline expansion enabled. But only so much.

Re: GNAT and register allocation

[Georg Bauhaus]

On 20.04.12 12:21, Georg Bauhaus wrote:
> Hi,
>
> in short, is there anything that one can do to make
> GNAT use many registers? MMX registers in particular,
> but not only.

SSE, that is, darn, the registers being named xmmN.

> It appears that the number of registers allocated increases
> with inline expansion enabled. But only so much.

In the (meaningless) example below, the translations of both
Comp.A and Comp.B will use the same set of registers, xmm0 .. xmm1.
If they were instead using xmm0 .. xmm1 and xmm2 .. xmm3,
respectively, speed might well double.


package Comp is

    type F is digits 15;

    function A (One, Two : F) return F;
    function B (One, Two : F) return F;

end Comp;

package body Comp is

    function A (One, Two : F) return F is
       X, Y, Z: F;
    begin
       X := One - 1.0;
       Y := Two / 3.14;
       Z := 2.0 * X + Y;
       return Z * Z;
    end A;

    function B (One, Two : F) return F is
       X, Y, Z: F;
    begin
       X := One + 1.0;
       Y := Two  * (1.0 / 3.14);
       Z := X + 2.0 * Y;
       return (Z * Z) / 3.0;
    end B;

    function Use_Them (Start : F) return F is
       Ra, Rb : F;
    begin
       Ra := Start;
       Rb := 0.0 - Start;
       for K in 1 .. 1_000_000 loop
          Ra := A (Ra, Rb);
          Rb := B (Ra, Rb);
       end loop;
       return (Ra + Rb) / 2.0;
    end Use_Them;

    Result : F;
    pragma Volatile (Result);
begin
    if Result'Valid then
       Result := Use_Them (Result);
    else
       raise Constraint_Error;
    end if;
end Comp;

Re: GNAT and register allocation

[Markus Schöpflin]

Am 20.04.2012 13:17, schrieb Georg Bauhaus:
> On 20.04.12 12:21, Georg Bauhaus wrote:
>> Hi,
>>
>> in short, is there anything that one can do to make
>> GNAT use many registers? MMX registers in particular,
>> but not only.
>
> SSE, that is, darn, the registers being named xmmN.
>
>> It appears that the number of registers allocated increases
>> with inline expansion enabled. But only so much.
>
> In the (meaningless) example below, the translations of both
> Comp.A and Comp.B will use the same set of registers, xmm0 .. xmm1.
> If they were instead using xmm0 .. xmm1 and xmm2 .. xmm3,
> respectively, speed might well double.

[snip code]

As long as the functions are not inlined, I'd expect them to obey the calling 
convention of the ABI of the platform on which they are compiled. Therefore 
you won't see A using xmm0/1 and B using xmm2/3.

If they are inlined however, things look quite different. Here is what I get 
when I compile your code:

---%<---
 > gnatmake -g -O3 comp
gcc-4.4 -c -g -O3 comp.adb

 > objdump -d comp.o

comp.o:     file format elf64-x86-64


Disassembly of section .text:
...
0000000000000050 <comp___elabb>:
...
   5b:   e8 00 00 00 00          callq  60 <comp___elabb+0x10>
   60:   84 c0                   test   %al,%al
   62:   0f 84 8f 00 00 00       je     f7 <comp___elabb+0xa7>
   68:   66 0f 57 c9             xorpd  %xmm1,%xmm1
   6c:   31 c0                   xor    %eax,%eax
   6e:   f2 0f 10 05 00 00 00    movsd  0x0(%rip),%xmm0        # 76 
<comp___elabb+0x26>
   75:   00
   76:   f2 0f 10 15 00 00 00    movsd  0x0(%rip),%xmm2        # 7e 
<comp___elabb+0x2e>
   7d:   00
   7e:   f2 0f 5c c8             subsd  %xmm0,%xmm1
   82:   f2 0f 10 35 00 00 00    movsd  0x0(%rip),%xmm6        # 8a 
<comp___elabb+0x3a>
   89:   00
   8a:   f2 0f 10 2d 00 00 00    movsd  0x0(%rip),%xmm5        # 92 
<comp___elabb+0x42>
   91:   00
   92:   f2 0f 10 25 00 00 00    movsd  0x0(%rip),%xmm4        # 9a 
<comp___elabb+0x4a>
   99:   00
   9a:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
   a0:   66 0f 28 d9             movapd %xmm1,%xmm3
   a4:   f2 0f 59 cd             mulsd  %xmm5,%xmm1
   a8:   f2 0f 5c c2             subsd  %xmm2,%xmm0
   ac:   83 c0 01                add    $0x1,%eax
   af:   f2 0f 5e de             divsd  %xmm6,%xmm3
   b3:   3d 40 42 0f 00          cmp    $0xf4240,%eax
   b8:   f2 0f 58 c9             addsd  %xmm1,%xmm1
   bc:   f2 0f 58 c0             addsd  %xmm0,%xmm0
   c0:   f2 0f 58 c3             addsd  %xmm3,%xmm0
   c4:   f2 0f 59 c0             mulsd  %xmm0,%xmm0
   c8:   66 0f 28 d8             movapd %xmm0,%xmm3
   cc:   f2 0f 58 da             addsd  %xmm2,%xmm3
   d0:   f2 0f 58 cb             addsd  %xmm3,%xmm1
   d4:   f2 0f 59 c9             mulsd  %xmm1,%xmm1
   d8:   f2 0f 5e cc             divsd  %xmm4,%xmm1
   dc:   75 c2                   jne    a0 <comp___elabb+0x50>
   de:   f2 0f 58 c1             addsd  %xmm1,%xmm0
   e2:   f2 0f 59 05 00 00 00    mulsd  0x0(%rip),%xmm0        # ea 
<comp___elabb+0x9a>
   e9:   00
   ea:   f2 0f 11 05 00 00 00    movsd  %xmm0,0x0(%rip)        # f2 
<comp___elabb+0xa2>
--->%---

As you can see, the xmmN registers up to xmm6 are used. Do you get different 
results?

Markus

Re: GNAT and register allocation

[Georg Bauhaus]

On 20.04.12 15:48, Markus Schöpflin wrote:

> As long as the functions are not inlined, I'd expect them to obey the calling
> convention of the ABI of the platform on which they are compiled. Therefore
> you won't see A using xmm0/1 and B using xmm2/3.

Ah, I see. When I add two more parameters, then xmm2 and xmm3
will appear. This would agree with my naive interpretation of
"x64 fpt values are passed in registers xmm{0..3}, others on
the stack." So I guess the ABI says that one may not select
arbitrary subsets from xmm{0..3} for passing just two parameters?

> As you can see, the xmmN registers up to xmm6 are used. Do you get different
> results?

Some results are very similar to yours. They depend on options, compiler,
OS, and CPU, though.

Some variance in addition results from both the depth and the amount of
"recursive expansion". What I am after, then, is how to control
inline expansion, insofar as it affects sets of registers in a single
compilation unit. (Assuming I can do better than GCC's heuristic
apparatus.) I must use one set of options for an entire program
in this case.

I wish there were a pragma that is the opposite of pragma Inline.
After all, there is a pair Suppress/Unsuppress, too.

Re: GNAT and register allocation

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Some variance in addition results from both the depth and the amount of
> "recursive expansion". What I am after, then, is how to control
> inline expansion, insofar as it affects sets of registers in a single
> compilation unit. (Assuming I can do better than GCC's heuristic
> apparatus.) 

Ok.

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

Why?

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.

-- 
-- Stephe

Re: GNAT and register allocation

[Florian Weimer]

* Georg Bauhaus:

> I wish there were a pragma that is the opposite of pragma Inline.

This might not do what you'd expect because even without inlining,
intra-procedural optimizations might still apply.

Re: GNAT and register allocation

[Georg Bauhaus]

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.

Re: GNAT and register allocation

[Georg Bauhaus]

On 21.04.12 17:41, Florian Weimer wrote:
> * Georg Bauhaus:
>
>> I wish there were a pragma that is the opposite of pragma Inline.
>
> This might not do what you'd expect because even without inlining,
> intra-procedural optimizations might still apply.

Still, a pragma controlling inline expansion (not just the enabling
pramga that Ada has) seems a more pragma-tic way of specifying what
I'd like, in the shape of a clearly visible request. (The compiler
may still ignore it).
Controlling inline expansion by playing with sizes of subprograms
seems possible, but a little adventurous.

Currently, I see only one way, writing a forest of
options for translating units of re-structured programs...

Re: GNAT and register allocation

[Georg Bauhaus]

On 21.04.12 14:10, Stephen Leake wrote:
> 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.

Wasn't there some message saying,
    "cannot inline before body seen"?

So preventing visibility of bodies might be another way of preventing
inline expansion.

Re: GNAT and register allocation

[Jacob Sparre Andersen]

Georg Bauhaus wrote:

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

> This requirement is likely a fact (external) that we can't change.

But aren't you adhering to the requirement, if you execute "gnatmake -P
some_project_file" to build the entire program?  Or is it mandated that
each child process of "gnatmake" should have the same build options?

Do you know (and are you free to tell us) the rationale for the
requirement?

Greetings,

Jacob
-- 
recursive, adj.; see recursive

Re: GNAT and register allocation

[gautier_niouzes]

Le dimanche 22 avril 2012 18:53:46 UTC+2, Georg Bauhaus a écrit :

> Still, a pragma controlling inline expansion (not just the enabling
> pramga that Ada has) seems a more pragma-tic way of specifying what
> I'd like, in the shape of a clearly visible request. (The compiler
> may still ignore it).
> Controlling inline expansion by playing with sizes of subprograms
> seems possible, but a little adventurous.
> 
> Currently, I see only one way, writing a forest of
> options for translating units of re-structured programs...

Did you consider the -gnatn option (rather: not using it...) ?
"-gnatn    Enable pragma Inline (both within and across units)"
(the "within" is relatively new: IIRC -gnatn was controlling only cross-unit inlining some time ago).
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: GNAT and register allocation

[Georg Bauhaus]

On 22.04.12 19:39, Jacob Sparre Andersen wrote:
> Georg Bauhaus wrote:
>
>>>> I must use one set of options for an entire program in this case.
>
>> This requirement is likely a fact (external) that we can't change.
>
> But aren't you adhering to the requirement, if you execute "gnatmake -P
> some_project_file" to build the entire program?  Or is it mandated that
> each child process of "gnatmake" should have the same build options?
>
> Do you know (and are you free to tell us) the rationale for the
> requirement?

It's nothing spectacular; the setup of a many languages project
(nothing critical, but possibly reputational ;-) is currently such
that its central circuits invoke translators with options.
That is, no configuration files or anything.  One reason for this
restriction is---I am just guessing here---that the makers of the
setup have enough work to do and would not want to tackle yet another
configuration language. Also, the use of configuration files is
less transparent to users of other languages than just switches;
they make things more understandable and more comparable.
And this kind of control works with pretty much every language

Re: GNAT and register allocation

[Georg Bauhaus]

On 22.04.12 22:53, gautier_niouzes@hotmail.com wrote:
> Le dimanche 22 avril 2012 18:53:46 UTC+2, Georg Bauhaus a �crit :
>
>> Still, a pragma controlling inline expansion (not just the enabling
>> pramga that Ada has) seems a more pragma-tic way of specifying what
>> I'd like, in the shape of a clearly visible request. (The compiler
>> may still ignore it).
>> Controlling inline expansion by playing with sizes of subprograms
>> seems possible, but a little adventurous.
>>
>> Currently, I see only one way, writing a forest of
>> options for translating units of re-structured programs...
>
> Did you consider the -gnatn option (rather: not using it...) ?

Yes, and many other things: there is also the trade-off between -gnatN
(deprecated in newer GNATs that rely on more recently added GCC powers)
and -gnatn, and nothing, and -O3 and -O2, and ... and compiler versions,
and a number of different CPUs, all offering different capabilities
(pipelines, buffers, versions of SSE, ...) and OS versions (both 32 bits
and 64 bits) ... that all affect the running time of programs.

Massively in this case.

Sometimes the effects of any combination of the above are rather striking,
yielding speedups or slowdowns in the range 0 .. 300 percent, for the
exact same program. The goal is to find ways to control the compilers
so that they produce predictably good result at least when the programs
are run on a subset of CPUs known in advance.

Re: GNAT and register allocation

[gautier_niouzes]

> The goal is to find ways to control the compilers
> so that they produce predictably good result at least when the programs
> are run on a subset of CPUs known in advance.

Any chance to use a combination of Ada-to-C precompiler + Intel C compiler ?
My impression is that the Intel compilers are more successful in finding the right blend of options itself, and with less effort for the programmer...

Cheers

G.

Re: GNAT and register allocation

[gautier_niouzes]

Just to make things more complicated ;-) : I suppose you also played with -O2 and the following options ?

-funroll-loops
-fpeel-loops
-ftracer
-funswitch-loops
-fweb
-frename-registers
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/ 

Re: GNAT and register allocation

[Georg Bauhaus]

On 23.04.12 10:43, gautier_niouzes@hotmail.com wrote:
>> The goal is to find ways to control the compilers
>> so that they produce predictably good result at least when the programs
>> are run on a subset of CPUs known in advance.
> 
> Any chance to use a combination of Ada-to-C precompiler + Intel C compiler ?

No, this needs to be GNAT. GCC can be quite good when compared
against Intel's compiler; the Ada parts works fine in many cases.

A surprising (to the layman) effect, and a desirable one,
occurs with SSE instructions for 64 bit operands.
In some cases, GNAT seemingly utilizes the split nature
of the SSE registers. This is just what I'd want when
the goal is to have an algorithm that runs in different
environments without change because it is just Ada.
No fancy __macros.

Re: GNAT and register allocation

[Georg Bauhaus]

On 23.04.12 11:11, gautier_niouzes@hotmail.com wrote:
> Just to make things more complicated ;-) : I suppose you also played with -O2 and the following options ?
> 
> -funroll-loops
> -fpeel-loops
> -ftracer
> -funswitch-loops
> -fweb
> -frename-registers

Some, and I have tried -fprofile-{generate,use}. There is an effect,
but nothing spectacular, or portable.

Re: GNAT and register allocation

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

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

Sounds like a bad rule; do they tell you to use C? or to use -O3 instead
of -O2? This is a decision that should be left to the people running the
Makefiles!

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

Yes.

> 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 don't know; the manual isn't very clear. A little experimentation
would tell.

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

Right.

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

I guess you mean 'a pragma I can include in the current source files,
that applies to specific subprograms'.

Yes, that would be simpler. The command line options have the advantage
of being available now :).

-- 
-- Stephe

Re: GNAT and register allocation

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> On 22.04.12 19:39, Jacob Sparre Andersen wrote:
>> Georg Bauhaus wrote:
>>
>>>>> I must use one set of options for an entire program in this case.
>>
>>> This requirement is likely a fact (external) that we can't change.
>>
>> But aren't you adhering to the requirement, if you execute "gnatmake -P
>> some_project_file" to build the entire program?  Or is it mandated that
>> each child process of "gnatmake" should have the same build options?
>>
>> Do you know (and are you free to tell us) the rationale for the
>> requirement?
>
> It's nothing spectacular; the setup of a many languages project
> (nothing critical, but possibly reputational ;-) is currently such
> that its central circuits invoke translators with options.
> That is, no configuration files or anything.  One reason for this
> restriction is---I am just guessing here---that the makers of the
> setup have enough work to do and would not want to tackle yet another
> configuration language. Also, the use of configuration files is
> less transparent to users of other languages than just switches;
> they make things more understandable and more comparable.

I think (well-written) gpr files are _much_ more understandable than
comparable makefiles for C!

Tell them the .gpr is just another source file, that _you_ maintain; why
should they care? Other source files are named on command lines for
other translators.

> And this kind of control works with pretty much every language

And you can do anything in assembler.

-- 
-- Stephe

Re: GNAT and register allocation

[Georg Bauhaus]

On 24.04.12 14:24, Stephen Leake wrote:

> I think (well-written) gpr files are _much_ more understandable than
> comparable makefiles for C!

Yes, GNAT project files are understandable, though non-portable TTBOMK.
(I find its idiolect a little inconsistent WRT to plurals and lists.)

Gpr files will likely not be used by those who code for Intel's
Fortran compiler, or the C part of GCC; they can easily specify
IFCOPTS or GCCOPTS referenced in Makefiles.

The Makefile for all C programs, or C++ programs, and a number of other
languages currently looks simlar to this:

%.c : %.systematic-name
	mv $< $@

%.executable : %.c
	$(CC) -pipe -Wall $(COPTS) $(GCCOPTS) $< -o $@

So the source text can be all in one file, the translation is kept simple.
GNAT also gets only two lines, one for gnatchop, the other for gnatmake.

"gnatchop" and ".gpr" files? (Was: GNAT and register allocation)

[Jacob Sparre Andersen]

Georg Bauhaus wrote:

> So the source text can be all in one file, the translation is kept
> simple.  GNAT also gets only two lines, one for gnatchop, the other
> for gnatmake.

Which leads me to the question - why doesn't gnatchop identify GNAT
project files as well as Ada specifications and bodies?

Greetings,

Jacob
-- 
"Friends don't let friends program in C++." -- Ludovic Brenta.

Re: GNAT and register allocation

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> On 24.04.12 14:24, Stephen Leake wrote:
>
>> I think (well-written) gpr files are _much_ more understandable than
>> comparable makefiles for C!
>
> Yes, GNAT project files are understandable, though non-portable TTBOMK.

What do you mean by "portable" here?

> Gpr files will likely not be used by those who code for Intel's
> Fortran compiler, or the C part of GCC; they can easily specify
> IFCOPTS or GCCOPTS referenced in Makefiles.

Why is that relevant?

People coding for Ada won't use IFCOPTS or GCCOPTS either.

On the other hand, people coding for C and Fortran _can_ use gpr files;
they work with anything that looks like a compiler (_not_ limited to Gnu
tools). But they don't have to just because you do.

> The Makefile for all C programs, or C++ programs, and a number of other
> languages currently looks simlar to this:
>
> %.c : %.systematic-name
> 	mv $< $@
>
> %.executable : %.c
> 	$(CC) -pipe -Wall $(COPTS) $(GCCOPTS) $< -o $@
>
> So the source text can be all in one file, the translation is kept simple.
> GNAT also gets only two lines, one for gnatchop, the other for gnatmake.

So if that gnatmake line includes -P<file>, and <file> is kept with the
rest of the Ada source code, what's the problem?

-- 
-- Stephe

Re: GNAT and register allocation

[Georg Bauhaus]

On 25.04.12 13:51, Stephen Leake wrote:

>> Yes, GNAT project files are understandable, though non-portable TTBOMK.
> 
> What do you mean by "portable" here?

Portable from one compiler to another. The Ada programs typically
are portable as-is.

>> Gpr files will likely not be used by those who code for Intel's
>> Fortran compiler, or the C part of GCC; they can easily specify
>> IFCOPTS or GCCOPTS referenced in Makefiles.
> 
> Why is that relevant?

> So if that gnatmake line includes -P<file>, and <file> is kept with the
> rest of the Ada source code, what's the problem?

The problem is that there exists a setup, and personnel (P), and
(1) there is a script
(2) that processes a .ini file (common to all languages)
(3) runs a simple makefile injecting few variables from step (2)
(4) for all languages (more than a dozen).

In the interest of manageability and transparency to (P), things are
to be kept simple and comparable, as far as I understand previous
comments. The programs do change every now and then.
The configuration files would have to change, too.
Such changes need to be checked by (P), for all languages,
in order to prevent anything that in effect violates some rules.

Ideally, settings commonly used by all compilers, such as "optimize",
or "use this hardware",  will be sufficiently effective and understood
by all compilers. In fact, an earlier version of the GNAT make rule had
been referring to COPTS, which was -O3 -fomit-frame-pointer; the C++
rule did the same, I think. Fortran cannot refer to GCCish COPTS, since
they switched to Intel Fortran.

Re: GNAT and register allocation

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> On 25.04.12 13:51, Stephen Leake wrote:
>
>>> Yes, GNAT project files are understandable, though non-portable TTBOMK.
>> 
>> What do you mean by "portable" here?
>
> Portable from one compiler to another. The Ada programs typically
> are portable as-is.

Ok. But the C and Fortran compiler options are equally non-portable, so
I don't see this as significant.

>>> Gpr files will likely not be used by those who code for Intel's
>>> Fortran compiler, or the C part of GCC; they can easily specify
>>> IFCOPTS or GCCOPTS referenced in Makefiles.
>> 
>> Why is that relevant?
>
>> So if that gnatmake line includes -P<file>, and <file> is kept with the
>> rest of the Ada source code, what's the problem?
>
> The problem is that there exists a setup, and personnel (P), and
> (1) there is a script
> (2) that processes a .ini file (common to all languages)
> (3) runs a simple makefile injecting few variables from step (2)
> (4) for all languages (more than a dozen).
>
> In the interest of manageability and transparency to (P), things are
> to be kept simple and comparable, as far as I understand previous
> comments. The programs do change every now and then.
> The configuration files would have to change, too.
> Such changes need to be checked by (P), for all languages,
> in order to prevent anything that in effect violates some rules.

So the Ada programers are required to understand the C and Fortran
compiler options well enough to maintain them? And conversely, the C and
Fortran people are expected to maintain the Ada compiler options.

That doesn't sound reasonable to me.

I will grant that the gpr files are not as well documented as the
compiler options; it is not possible to determine which package should
contain any given compiler option.

If that were fixed, I think it's reasonable to expect anyone who can
maintain makefiles and compiler options in general to maintain gpr files.

And as I have said, in the long run everyone would gain if everyone
switched to gpr files.

> Ideally, settings commonly used by all compilers, such as "optimize",
> or "use this hardware",  will be sufficiently effective and understood
> by all compilers. 

Do you mean "spelled the same for all compilers" or "all compilers will
have an option similar enough in meaning". I'd expect the latter, but
not the former.

> In fact, an earlier version of the GNAT make rule had been referring
> to COPTS, which was -O3 -fomit-frame-pointer; the C++ rule did the
> same, I think. Fortran cannot refer to GCCish COPTS, since they
> switched to Intel Fortran.

And did anyone object to that "non-compatible options" change?

-- 
-- Stephe

Re: GNAT and register allocation

[Georg Bauhaus]

On 26.04.12 12:55, Stephen Leake wrote:

> So the Ada programers are required to understand the C and Fortran
> compiler options well enough to maintain them?

Language X programmers need not maintain language Y switches
and vice versa, but they will want to understand them; Ada programmers
are also required to pick switches that are reasonably simple,
comparable, and not overly program-specific. Deviating from standard
options requires a convincing reason. (There is at least one such case.)



> If that were fixed, I think it's reasonable to expect anyone who can
> maintain makefiles and compiler options in general to maintain gpr files.

GNAT project files, or something equivalent taken from some other
language's implementation, could create an organizational problem
in two ways.

1. There is no question that good configuration files are superior
to switches, in particular if configuration files are more than syntax
around switches. However, since configuration files are superior,
they create a major asymmetry if another language's setup cannot be
controlled in the same way. And even if, they'd force everyone under
the rule of a possibly "foreign" control. This is simply not viable.

2. The configuration is done by "central services". They want
simplicity and comparability, possibly at the expense of some
minor disadvantages for one or other implementation language.


> And did anyone object to that "non-compatible options" change?

I think no one objected to necessary adjustments caused by a different
dialect of switches, and the Intel Fortran switches are "by the rules".