* GNAT and register allocation @ 2012-04-20 10:21 Georg Bauhaus 2012-04-20 11:17 ` Georg Bauhaus 0 siblings, 1 reply; 25+ messages in thread From: Georg Bauhaus @ 2012-04-20 10:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-20 10:21 GNAT and register allocation Georg Bauhaus @ 2012-04-20 11:17 ` Georg Bauhaus 2012-04-20 13:48 ` Markus Schöpflin 0 siblings, 1 reply; 25+ messages in thread From: Georg Bauhaus @ 2012-04-20 11:17 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-20 11:17 ` Georg Bauhaus @ 2012-04-20 13:48 ` Markus Schöpflin 2012-04-20 15:34 ` Georg Bauhaus 0 siblings, 1 reply; 25+ messages in thread From: Markus Schöpflin @ 2012-04-20 13:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-20 13:48 ` Markus Schöpflin @ 2012-04-20 15:34 ` Georg Bauhaus 2012-04-21 12:10 ` Stephen Leake 2012-04-21 15:41 ` Florian Weimer 0 siblings, 2 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-20 15:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-20 15:34 ` Georg Bauhaus @ 2012-04-21 12:10 ` Stephen Leake 2012-04-22 16:43 ` Georg Bauhaus 2012-04-22 17:30 ` Georg Bauhaus 2012-04-21 15:41 ` Florian Weimer 1 sibling, 2 replies; 25+ messages in thread From: Stephen Leake @ 2012-04-21 12:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-21 12:10 ` Stephen Leake @ 2012-04-22 16:43 ` Georg Bauhaus 2012-04-22 17:39 ` Jacob Sparre Andersen 2012-04-24 12:21 ` Stephen Leake 2012-04-22 17:30 ` Georg Bauhaus 1 sibling, 2 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-22 16:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 16:43 ` Georg Bauhaus @ 2012-04-22 17:39 ` Jacob Sparre Andersen 2012-04-22 21:14 ` Georg Bauhaus 2012-04-24 12:21 ` Stephen Leake 1 sibling, 1 reply; 25+ messages in thread From: Jacob Sparre Andersen @ 2012-04-22 17:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 17:39 ` Jacob Sparre Andersen @ 2012-04-22 21:14 ` Georg Bauhaus 2012-04-24 12:24 ` Stephen Leake 0 siblings, 1 reply; 25+ messages in thread From: Georg Bauhaus @ 2012-04-22 21:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 21:14 ` Georg Bauhaus @ 2012-04-24 12:24 ` Stephen Leake 2012-04-24 13:27 ` Georg Bauhaus 0 siblings, 1 reply; 25+ messages in thread From: Stephen Leake @ 2012-04-24 12:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-24 12:24 ` Stephen Leake @ 2012-04-24 13:27 ` Georg Bauhaus 2012-04-24 18:40 ` "gnatchop" and ".gpr" files? (Was: GNAT and register allocation) Jacob Sparre Andersen 2012-04-25 11:51 ` GNAT and register allocation Stephen Leake 0 siblings, 2 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-24 13:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* "gnatchop" and ".gpr" files? (Was: GNAT and register allocation) 2012-04-24 13:27 ` Georg Bauhaus @ 2012-04-24 18:40 ` Jacob Sparre Andersen 2012-04-25 11:51 ` GNAT and register allocation Stephen Leake 1 sibling, 0 replies; 25+ messages in thread From: Jacob Sparre Andersen @ 2012-04-24 18:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-24 13:27 ` Georg Bauhaus 2012-04-24 18:40 ` "gnatchop" and ".gpr" files? (Was: GNAT and register allocation) Jacob Sparre Andersen @ 2012-04-25 11:51 ` Stephen Leake 2012-04-25 12:54 ` Georg Bauhaus 1 sibling, 1 reply; 25+ messages in thread From: Stephen Leake @ 2012-04-25 11:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-25 11:51 ` GNAT and register allocation Stephen Leake @ 2012-04-25 12:54 ` Georg Bauhaus 2012-04-26 10:55 ` Stephen Leake 0 siblings, 1 reply; 25+ messages in thread From: Georg Bauhaus @ 2012-04-25 12:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-25 12:54 ` Georg Bauhaus @ 2012-04-26 10:55 ` Stephen Leake 2012-04-26 17:15 ` Georg Bauhaus 0 siblings, 1 reply; 25+ messages in thread From: Stephen Leake @ 2012-04-26 10:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-26 10:55 ` Stephen Leake @ 2012-04-26 17:15 ` Georg Bauhaus 0 siblings, 0 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-26 17:15 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 16:43 ` Georg Bauhaus 2012-04-22 17:39 ` Jacob Sparre Andersen @ 2012-04-24 12:21 ` Stephen Leake 1 sibling, 0 replies; 25+ messages in thread From: Stephen Leake @ 2012-04-24 12:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-21 12:10 ` Stephen Leake 2012-04-22 16:43 ` Georg Bauhaus @ 2012-04-22 17:30 ` Georg Bauhaus 1 sibling, 0 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-22 17:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-20 15:34 ` Georg Bauhaus 2012-04-21 12:10 ` Stephen Leake @ 2012-04-21 15:41 ` Florian Weimer 2012-04-22 16:53 ` Georg Bauhaus 1 sibling, 1 reply; 25+ messages in thread From: Florian Weimer @ 2012-04-21 15:41 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-21 15:41 ` Florian Weimer @ 2012-04-22 16:53 ` Georg Bauhaus 2012-04-22 20:53 ` gautier_niouzes 0 siblings, 1 reply; 25+ messages in thread From: Georg Bauhaus @ 2012-04-22 16:53 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 16:53 ` Georg Bauhaus @ 2012-04-22 20:53 ` gautier_niouzes 2012-04-22 21:24 ` Georg Bauhaus 0 siblings, 1 reply; 25+ messages in thread From: gautier_niouzes @ 2012-04-22 20:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 20:53 ` gautier_niouzes @ 2012-04-22 21:24 ` Georg Bauhaus 2012-04-23 8:43 ` gautier_niouzes 2012-04-23 9:11 ` gautier_niouzes 0 siblings, 2 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-22 21:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 21:24 ` Georg Bauhaus @ 2012-04-23 8:43 ` gautier_niouzes 2012-04-23 16:46 ` Georg Bauhaus 2012-04-23 9:11 ` gautier_niouzes 1 sibling, 1 reply; 25+ messages in thread From: gautier_niouzes @ 2012-04-23 8:43 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-23 8:43 ` gautier_niouzes @ 2012-04-23 16:46 ` Georg Bauhaus 0 siblings, 0 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-23 16:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-22 21:24 ` Georg Bauhaus 2012-04-23 8:43 ` gautier_niouzes @ 2012-04-23 9:11 ` gautier_niouzes 2012-04-23 16:47 ` Georg Bauhaus 1 sibling, 1 reply; 25+ messages in thread From: gautier_niouzes @ 2012-04-23 9:11 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: GNAT and register allocation 2012-04-23 9:11 ` gautier_niouzes @ 2012-04-23 16:47 ` Georg Bauhaus 0 siblings, 0 replies; 25+ messages in thread From: Georg Bauhaus @ 2012-04-23 16:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2012-04-26 17:15 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-20 10:21 GNAT and register allocation Georg Bauhaus 2012-04-20 11:17 ` Georg Bauhaus 2012-04-20 13:48 ` Markus Schöpflin 2012-04-20 15:34 ` Georg Bauhaus 2012-04-21 12:10 ` Stephen Leake 2012-04-22 16:43 ` Georg Bauhaus 2012-04-22 17:39 ` Jacob Sparre Andersen 2012-04-22 21:14 ` Georg Bauhaus 2012-04-24 12:24 ` Stephen Leake 2012-04-24 13:27 ` Georg Bauhaus 2012-04-24 18:40 ` "gnatchop" and ".gpr" files? (Was: GNAT and register allocation) Jacob Sparre Andersen 2012-04-25 11:51 ` GNAT and register allocation Stephen Leake 2012-04-25 12:54 ` Georg Bauhaus 2012-04-26 10:55 ` Stephen Leake 2012-04-26 17:15 ` Georg Bauhaus 2012-04-24 12:21 ` Stephen Leake 2012-04-22 17:30 ` Georg Bauhaus 2012-04-21 15:41 ` Florian Weimer 2012-04-22 16:53 ` Georg Bauhaus 2012-04-22 20:53 ` gautier_niouzes 2012-04-22 21:24 ` Georg Bauhaus 2012-04-23 8:43 ` gautier_niouzes 2012-04-23 16:46 ` Georg Bauhaus 2012-04-23 9:11 ` gautier_niouzes 2012-04-23 16:47 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox