* Pragma Inline and its Effects of Compilation Dependencies. @ 2000-03-20 0:00 Ralph Corderoy 2000-03-21 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Ralph Corderoy @ 2000-03-20 0:00 UTC (permalink / raw) Hi, 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. Assume we've two packages, foo and bar, with bar making use of foo. ==> foo.s.ada <== package foo is procedure x; procedure y; pragma inline(y); end; ==> foo.b.ada <== package body foo is procedure x is separate; procedure y is separate; end; ==> foo.x.ada <== separate(foo) procedure x is begin null; end; ==> foo.y.ada <== separate(foo) procedure y is begin null; end; ==> bar.s.ada <== with foo; package bar is procedure x; procedure y; end; ==> bar.b.ada <== package body bar is procedure x is separate; procedure y is separate; end; ==> bar.x.ada <== separate(bar) procedure x is begin foo.y; end; ==> bar.y.ada <== separate(bar) procedure y is begin null; end; Are these the dependencies that exist. 1 foo.b.ada -> foo.s.ada because a body depends on its spec 2 foo.x.ada -> foo.b.ada because a sub-unit depends on its parent 3 foo.y.ada -> foo.b.ada because a sub-unit depends on its parent 4 bar.b.ada -> bar.s.ada because a body depends on its spec 5 bar.x.ada -> bar.b.ada because a sub-unit depends on its parent 6 bar.y.ada -> bar.b.ada because a sub-unit depends on its parent 7 bar.s.ada -> foo.s.ada because bar's spec withs foo 8 bar.x.ada -> foo.y.ada because bar.x calls inlined foo.y A linear ordering of this partial order is foo.s.ada foo.b.ada foo.x.ada foo.y.ada bar.s.ada bar.b.ada bar.x.ada bar.y.ada The compiler suite I was using had instead 8 bar.x.ada -> foo.b.ada allowing it to use the linear ordering foo.s.ada foo.b.ada bar.s.ada bar.b.ada bar.x.ada bar.y.ada foo.x.ada foo.y.ada This fails to inline foo.y because it isn't available when bar.x is built. I believe calling an inlined routine creates a dependency from the caller to the routine itself, and if it is a separate that isn't the same as the body of the package, as used by the compiler above. First question. How well do other compilers handle this; not too well judging by the the existence of adamakegen (http://www.ics.uci.edu/~softtest/adamakegen.html) and its complaints about Verdix/SunAda. I've read a little about gnat's gnatmake and how the compiler doesn't follow the normal library implementation and instead uses the source files coupled with ALI files. Does that mean in practice it copes correctly with inline dependencies, including when they're in separates? The manual seemed to suggest it didn't consider source outside the current library. That wouldn't help in my case. Consider if foo was being built into a separate Ada library from bar; I alter foo.y.ada and build locally there. I then want to move to bar's library and find it is out of date. It seems what I need is something that will take many source files, parse them, and spit out the dependencies for use in something like a traditional makefile. It isn't a trivial task as things like package renames and use clauses help to obscure what is being called. Plus it mustn't make the mistake of thinking an inline creates a dependency to the package body when a separate exists. Does something like this exist? The alternative seems to be to re-build bar from scratch whenever foo is changed because it can't be left to the compiler to calculate what to rebuild and relying on the programmer to know who calls foo.y is a no-no. But building bar and everything else could take eons. This can't be an original problem. What do people with large Ada projects do? Ralph. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-20 0:00 Pragma Inline and its Effects of Compilation Dependencies Ralph Corderoy @ 2000-03-21 0:00 ` Robert Dewar 2000-03-21 0:00 ` Paul Graham 2000-03-23 0:00 ` Ralph Corderoy 2000-03-21 0:00 ` Samuel T. Harris 2000-03-22 0:00 ` Robert Dewar 2 siblings, 2 replies; 22+ messages in thread From: Robert Dewar @ 2000-03-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-21 0:00 ` Robert Dewar @ 2000-03-21 0:00 ` Paul Graham 2000-03-21 0:00 ` Gautier 2000-03-22 0:00 ` Ken Garlington 2000-03-23 0:00 ` Ralph Corderoy 1 sibling, 2 replies; 22+ messages in thread From: Paul Graham @ 2000-03-21 0:00 UTC (permalink / raw) Robert Dewar wrote: > 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. Makes you wonder why the library-based method of compilation was used in the first place. Perhaps the intent was to save compilation time by not recompiling package sources each time they are USEd in another unit. Paul ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-21 0:00 ` Paul Graham @ 2000-03-21 0:00 ` Gautier 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Ken Garlington 1 sibling, 1 reply; 22+ messages in thread From: Gautier @ 2000-03-21 0:00 UTC (permalink / raw) > > 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. Paul Graham wrote: > Makes you wonder why the library-based method of compilation was used in > the first place. Perhaps the intent was to save compilation time by not > recompiling package sources each time they are USEd in another unit. This feature doesn't force the library model in the classical Ada83 way. E.g. Turbo Pascal and successors/clones. Or maybe the "other" Ada95 compilers ? And it doesn't prevent accurate inlining if compiled specification holds rich enough information (e.g. from where to pick the procedure to inline in the source of package body, or some representation of it ?) ______________________________________________________ Gautier -- http://members.xoom.com/gdemont/gsoft.htm ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-21 0:00 ` Gautier @ 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Larry Kilgallen 2000-03-22 0:00 ` Wes Groleau 0 siblings, 2 replies; 22+ messages in thread From: Robert Dewar @ 2000-03-22 0:00 UTC (permalink / raw) In article <38D7F4D8.1AE44625@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote: > This feature doesn't force the library model in the classical Ada83 way. > E.g. Turbo Pascal and successors/clones. Or maybe the "other" Ada95 compilers ? > And it doesn't prevent accurate inlining if compiled specification holds > rich enough information (e.g. from where to pick the procedure to inline > in the source of package body, or some representation of it ?) You miss the point. The Ada 83 library approach is based on the idea that a compilation NEVER accesses anything that has not been previously compiled. That is quite fundamental to the model. If you are talking about looking at sources of things that have not been compiled yet, then you are talking about the other model (the source based model). Once again, to be clear, the classical Ada 83 model has a compilation process that is library x single-source ----------> updated library compile The source based model has a quite different compilation process that looks like all-other-sources x one identified source -------> object compile Further details are in the existing literature. As I said earlier, the only way to do full inlining with the classical library model is to delay inlining until binding, which is a very heavy burden, since it means delaying much or even all code generation till bind time. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Robert Dewar @ 2000-03-22 0:00 ` Larry Kilgallen 2000-03-22 0:00 ` Ted Dennison 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Wes Groleau 1 sibling, 2 replies; 22+ messages in thread From: Larry Kilgallen @ 2000-03-22 0:00 UTC (permalink / raw) In article <8b94tg$9jt$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> writes: > You miss the point. The Ada 83 library approach is based on the > idea that a compilation NEVER accesses anything that has not > been previously compiled. That is quite fundamental to the > model. If you are talking about looking at sources of things > that have not been compiled yet, then you are talking about > the other model (the source based model). > > Once again, to be clear, the classical Ada 83 model has a > compilation process that is > > library x single-source ----------> updated library > compile > > The source based model has a quite different compilation > process that looks like > > all-other-sources x one identified source -------> object > compile How would you classify a mechanism like the DEC Ada command ACS LOAD ? From my perspective as a user it takes away any need for me to worry about the order of compilation even on a clean build to an empty library. Certainly the fact that it looks at all the sources takes more time, but my general experience is that there are only two categories of compilation durations: short enough that I will sit and wait long enough that I will go do something else Larry Kilgallen ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Larry Kilgallen @ 2000-03-22 0:00 ` Ted Dennison 2000-03-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 22+ messages in thread From: Ted Dennison @ 2000-03-22 0:00 UTC (permalink / raw) In article <2000Mar22.085654.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > In article <8b94tg$9jt$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> writes: > > > You miss the point. The Ada 83 library approach is based on the > > idea that a compilation NEVER accesses anything that has not > > been previously compiled. That is quite fundamental to the > How would you classify a mechanism like the DEC Ada command > ACS LOAD ? From my perspective as a user it takes away any > need for me to worry about the order of compilation even on > a clean build to an empty library. Its been a while (almost a decade). But as I recall, that command only built up a list of units along with a mapping to their sources. As it did not actually compile anything, it would not be considered a "compilation" in the discussion above. Just about every library-based model provides a way to introduce units to the library without compiling them first. But in this state they are indeed not compiled at all, so I don't think it affects the discussion about inlining. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Larry Kilgallen 2000-03-22 0:00 ` Ted Dennison @ 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 22+ messages in thread From: Robert Dewar @ 2000-03-22 0:00 UTC (permalink / raw) In article <2000Mar22.085654.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > How would you classify a mechanism like the DEC Ada command > ACS LOAD ? From my perspective as a user it takes away any > need for me to worry about the order of compilation even on > a clean build to an empty library. This is a separate utility that determines what needs compiling, and of course all Ada systems have such tools, and that is true for both models. BUT, and this is a big but, and what this thread is all about, whether inlining takes place will typically depend on the order of compilation, and tools like ACS LOAD a) often don't take inlining into account b) often can't take inlining into account in the sense that they cannot deal with mutual inlining, because there is no realiable order in such cases. In this situation the tool cannot make the "right" choice, and at best tells you the problem, at worst (and most typically) steams ahead and makes an arbitrary choice without telling you. It may take away your worry, but that does not mean there is nothing to worry about. I do not know for sure what the DEC Ada 83 approach to inlining is but it would surprise me if it did inlining at bind time. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Robert Dewar @ 2000-03-22 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 22+ messages in thread From: Larry Kilgallen @ 2000-03-22 0:00 UTC (permalink / raw) In article <8bat53$6qb$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > I do not know for sure what the DEC Ada 83 approach to inlining > is but it would surprise me if it did inlining at bind time. I know the capabilities of the VMS Linker, and they do not include anything elaborate enough to do inlining. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Larry Kilgallen @ 2000-03-22 0:00 ` Wes Groleau 2000-03-22 0:00 ` Robert A Duff 1 sibling, 1 reply; 22+ messages in thread From: Wes Groleau @ 2000-03-22 0:00 UTC (permalink / raw) > .... the only way to do full inlining with the classical > library model is to delay inlining until binding, which is > a very heavy burden, since it means delaying much or even all > code generation till bind time. I don't quite follow. If object code has been generated within file xx.o for function XX.Func, what prevents a code generator, when it reaches Rec.Field := XX.Func (P, Q); from streamlining the preamble and parameter setup and result assignment, and copying the rest of the object code as is. Or do you mean something else by "full" inlining? -- Wes Groleau http://freepages.genealogy.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Wes Groleau @ 2000-03-22 0:00 ` Robert A Duff 0 siblings, 0 replies; 22+ messages in thread From: Robert A Duff @ 2000-03-22 0:00 UTC (permalink / raw) Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes: > I don't quite follow. If object code has been generated within > file xx.o for function XX.Func, what prevents a code generator, > when it reaches > > Rec.Field := XX.Func (P, Q); > > from streamlining the preamble and parameter setup and result > assignment, and copying the rest of the object code as is. Inlining is generally not done at the object code level, but at the level of some intermediate language that is higher level than machine code. The point is not just to save the call and return instructions, but to optimize the inlined code based on information at the call site. Eg: function F(X: Color) return String is begin case X is when Red => return "This"; when Green => return "That"; ... end case; end F; Then if you inline a call like "F(Red)", the entire thing boils down to a compile-time-known value. - Bob ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-21 0:00 ` Paul Graham 2000-03-21 0:00 ` Gautier @ 2000-03-22 0:00 ` Ken Garlington 1 sibling, 0 replies; 22+ messages in thread From: Ken Garlington @ 2000-03-22 0:00 UTC (permalink / raw) I think the use of the library-based approach was due to a combination of things: - Vendors reading RM83 section 10.4 too closely: "a library file containing information on the compilation units of the program library must be maintained by the compiler..." - Assumptions about efficiency. - The desire to do things like distribute pre-compiled component sets without releasing the source code. The presumption was that this was better than just releasing object code, since there would be additional information for optimizations, support tools, etc. "Paul Graham" <pgraham@cadence.com> wrote in message news:38D7CABA.A73F88C6@cadence.com... > Robert Dewar wrote: > > > 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. > > Makes you wonder why the library-based method of compilation was used in > the > first place. Perhaps the intent was to save compilation time by not > recompiling > package sources each time they are USEd in another unit. > > Paul ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-21 0:00 ` Robert Dewar 2000-03-21 0:00 ` Paul Graham @ 2000-03-23 0:00 ` Ralph Corderoy 2000-03-23 0:00 ` Robert Dewar 1 sibling, 1 reply; 22+ messages in thread From: Ralph Corderoy @ 2000-03-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-23 0:00 ` Ralph Corderoy @ 2000-03-23 0:00 ` Robert Dewar 2000-03-24 0:00 ` Robert A Duff 0 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 2000-03-23 0:00 UTC (permalink / raw) In article <8bd7oh$6sv$1@inputplus.demon.co.uk>, ralph@inputplus.demon.co.uk (Ralph Corderoy) wrote: > 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. Strange indeed :-) The genesis of this idea was that Richard Stallman could not believe that a language where the meaning of the program depended on the order in which sources were compiled could even vaguely be acceptable :-). We patiently explained that the Ada RM required this, but he would not accept it, and eventually we wouldn't accept it either, and the Ada 95 RM was reworded to make clear that this (acceptable) interpretation of the Ada 83 RM is definitely legitimate :-) When we explored this idea further, we found it had tremendous advantages. Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-23 0:00 ` Robert Dewar @ 2000-03-24 0:00 ` Robert A Duff 0 siblings, 0 replies; 22+ messages in thread From: Robert A Duff @ 2000-03-24 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > The genesis of this idea was that Richard Stallman could not > believe that a language where the meaning of the program > depended on the order in which sources were compiled could > even vaguely be acceptable :-). And yet he seems perfectly happy with a language where the meaning of the program depends on the order in which the object code is loaded into the system -- Lisp. I certainly agree that the source-based model is a good one, and I've thought so since around 1984 or so. There are really two aspects to the source-based model, as supported by GNAT and the various compilers derived from the Intermetrics/AverStar front end: 1. The source is what matters. If you change the source code, rebuilding tools notice. Order of compilation doesn't matter. Compiling something twice produces the same result. Etc. 2. Symbol tables and whatnot are NOT stored in some sort of persistent data structure (disk files, or whatever), but are recomputed as needed. These are somewhat independent design decisions. That is, you could have number 1, but as an optimization store symbol tables on disk, so long as you make it a pure optimization (doesn't affect the semantics of the source-based model). Number 1 seems obviously Good to me. I'm not so sure about number 2. Clearly, not storing persistent data simplifies the compiler, which is a good thing. Especially since it won't *be* an optimization unless you go to some trouble to make sure the data structures are reasonably small -- you can do a lot of compiling in the time it takes to read stuff from the disk. - Bob ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-20 0:00 Pragma Inline and its Effects of Compilation Dependencies Ralph Corderoy 2000-03-21 0:00 ` Robert Dewar @ 2000-03-21 0:00 ` Samuel T. Harris 2000-03-23 0:00 ` Ralph Corderoy 2000-03-22 0:00 ` Robert Dewar 2 siblings, 1 reply; 22+ messages in thread From: Samuel T. Harris @ 2000-03-21 0:00 UTC (permalink / raw) Ralph Corderoy wrote: > > Hi, > > 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. > < <snip> > > I believe calling an inlined routine creates a dependency from the > caller to the routine itself, and if it is a separate that isn't the > same as the body of the package, as used by the compiler above. > > First question. How well do other compilers handle this; not too well > judging by the the existence of adamakegen > (http://www.ics.uci.edu/~softtest/adamakegen.html) and its complaints > about Verdix/SunAda. In my experience I observed the following results ... Alsys ala version 4: Usually worked, sometimes didn't. VADS ala version 4-6: Never works well. Rational R1000 and Apex: Always works except when mutual inlining is involved. This is a good area for ASIS based tools. I use just such a beast to help resolve this issue. On the other hand, I have also found that compilation orders which general place bodies as soon as possible rarely have this problem so building a tool to handle this case may not be worth while if your tool can do bodies ASAP. If I remember correctly, Alsys had a switch to control when bodies appear in the order. It could do as soon as possible or as late as possible. Note that when a compiler requires a generic body be compiled before it is instantiated, then you have the same basic requirements. > > I've read a little about gnat's gnatmake and how the compiler doesn't > follow the normal library implementation and instead uses the source > files coupled with ALI files. Does that mean in practice it copes > correctly with inline dependencies, including when they're in separates? > The manual seemed to suggest it didn't consider source outside the > current library. That wouldn't help in my case. Consider if foo was > being built into a separate Ada library from bar; I alter foo.y.ada and > build locally there. I then want to move to bar's library and find it > is out of date. > > It seems what I need is something that will take many source files, > parse them, and spit out the dependencies for use in something like a > traditional makefile. It isn't a trivial task as things like package > renames and use clauses help to obscure what is being called. Plus it > mustn't make the mistake of thinking an inline creates a dependency to > the package body when a separate exists. Does something like this > exist? This is easily written using ASIS queries. Lacking access to ASIS, one can get a yacc/lex grammars for Ada and do the extra work yourself. Hopefully, your compiler tool can spit out "normal" dependencies so you don't have to worry about context clauses. You only have to worry about which subprograms are inlines and where they are called. Using syntax processes will easily handle straight subprogram calls but requires more work if your code is using rename declarations. > > The alternative seems to be to re-build bar from scratch whenever foo is > changed because it can't be left to the compiler to calculate what to > rebuild and relying on the programmer to know who calls foo.y is a > no-no. But building bar and everything else could take eons. If your code is stable and your dependencies are not changing much, then you should capture the dependencies once and use that to determine the scope of recompilation. Even if you have to visually inspect for inline calls, you only need capture this once. Using VADS, you can use pragma inline_only and the compiler will complain when it can't inline the call. This feedback is crucial to maintaining your dependency information when you capture it manually. > > This can't be an original problem. What do people with large Ada > projects do? Such things are important to your compiler selection. If you need to change compilers in the future, support for this problem area needs to be on your list. In any event, you use what the compiler will give you and build anything else you need to the degree that it is worth building. > > Ralph. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-21 0:00 ` Samuel T. Harris @ 2000-03-23 0:00 ` Ralph Corderoy 2000-03-24 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 22+ messages in thread From: Ralph Corderoy @ 2000-03-23 0:00 UTC (permalink / raw) Hi Samuel, > This is a good area for ASIS based tools. I use just such a beast to > help resolve this issue. Can you expand on that? > On the other hand, I have also found that compilation orders which > general place bodies as soon as possible rarely have this problem so > building a tool to handle this case may not be worth while if your > tool can do bodies ASAP. It does, but the routines to be inlined are normally in separates, not the body, and due to the missing dependency they can be placed too late in the order. > > It seems what I need is something that will take many source files, > > parse them, and spit out the dependencies for use in something like > > a traditional makefile. It isn't a trivial task as things like > > package renames and use clauses help to obscure what is being > > called. Plus it mustn't make the mistake of thinking an inline > > creates a dependency to the package body when a separate exists. > > Does something like this exist? > > This is easily written using ASIS queries. Lacking access to ASIS, > one can get a yacc/lex grammars for Ada and do the extra work > yourself. Hopefully, your compiler tool can spit out "normal" > dependencies so you don't have to worry about context clauses. You > only have to worry about which subprograms are inlines and where they > are called. Using syntax processes will easily handle straight > subprogram calls but requires more work if your code is using rename > declarations. We might have access to ASIS but isn't that an interface to the DIANA standard intermediate format? Are you suggesting building everything once, ignoring warnings about missed inline opportunities, and then use ASIS to poke around the library to find the dependencies? I've picked up a yacc grammar with lex parser from John Levine's archive (one minor bug in the lexer), and it spits out some parts easily enough. Not sure if it is worth the hassle to add the necessary rename handling, etc., code; it might be easier for the project to burn some man hours on maintaining the order manually over the next few years. > > This can't be an original problem. What do people with large Ada > > projects do? > > Such things are important to your compiler selection. If you need to > change compilers in the future, support for this problem area needs > to be on your list. In any event, you use what the compiler will give > you and build anything else you need to the degree that it is worth > building. This is a project that is getting on for a decade old; all the hardware, OS, and compilers were specified years ago and we aren't allowed to change them now. Yes, development is still ongoing ;-) We could probably get away with an extra tool that worked out compilation order for us though. Ralph. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-23 0:00 ` Ralph Corderoy @ 2000-03-24 0:00 ` Samuel T. Harris 2000-03-24 0:00 ` Robert Dewar 0 siblings, 1 reply; 22+ messages in thread From: Samuel T. Harris @ 2000-03-24 0:00 UTC (permalink / raw) Ralph Corderoy wrote: > > Hi Samuel, > > > This is a good area for ASIS based tools. I use just such a beast to > > help resolve this issue. > > Can you expand on that? > > > On the other hand, I have also found that compilation orders which > > general place bodies as soon as possible rarely have this problem so > > building a tool to handle this case may not be worth while if your > > tool can do bodies ASAP. > > It does, but the routines to be inlined are normally in separates, not > the body, and due to the missing dependency they can be placed too > late in the order. I don't see why their being i separates presents a problem for ASAP body order. The package body will be placed in order as soon as its extra supporters are in order. Assuming your separate has no extra with clauses, then it will be placed immediately after the parent body. Doing bodies ASAP means units dependent upon the spec come after the body of the spec! > > > > It seems what I need is something that will take many source files, > > > parse them, and spit out the dependencies for use in something like > > > a traditional makefile. It isn't a trivial task as things like > > > package renames and use clauses help to obscure what is being > > > called. Plus it mustn't make the mistake of thinking an inline > > > creates a dependency to the package body when a separate exists. > > > Does something like this exist? > > > > This is easily written using ASIS queries. Lacking access to ASIS, > > one can get a yacc/lex grammars for Ada and do the extra work > > yourself. Hopefully, your compiler tool can spit out "normal" > > dependencies so you don't have to worry about context clauses. You > > only have to worry about which subprograms are inlines and where they > > are called. Using syntax processes will easily handle straight > > subprogram calls but requires more work if your code is using rename > > declarations. > > We might have access to ASIS but isn't that an interface to the DIANA > standard intermediate format? Are you suggesting building everything > once, ignoring warnings about missed inline opportunities, and then use > ASIS to poke around the library to find the dependencies? Not all compiler use DIANA trees. ASIS is a standard way to query the semantic nature of the program, regardless of its internal representation. ASIS code should be very portable across supported compilers. What I am suggesting is using a tool to capture ALL the dependencies (i.e. with clauses, generic bodies to their instantiations, pragma inline bodies, anything else you need) before initial compilation. However, as you point out, using the warning for failed inlines as feedback is also a alternative course of action. Given a "normal" dependency list, one can simply add more entries based on the inline warning you get. The problem with this is that you never know when you'll be done. Changes to code can siginficantly change the base order and cause more inline warnings. Your initial order may satisfy some inlining so these won't be captured explicitly in your dependency list. > > I've picked up a yacc grammar with lex parser from John Levine's > archive (one minor bug in the lexer), and it spits out some parts > easily enough. Not sure if it is worth the hassle to add the necessary > rename handling, etc., code; it might be easier for the project to > burn some man hours on maintaining the order manually over the next few > years. I gave up on this approach for any but the most basic stuff years ago when I discovered ASIS. It is much more work to do anything useful especially on a large project. ASIS is so much easier, but does have its own learning curve. > > > > This can't be an original problem. What do people with large Ada > > > projects do? > > > > Such things are important to your compiler selection. If you need to > > change compilers in the future, support for this problem area needs > > to be on your list. In any event, you use what the compiler will give > > you and build anything else you need to the degree that it is worth > > building. > > This is a project that is getting on for a decade old; all the > hardware, OS, and compilers were specified years ago and we aren't > allowed to change them now. Yes, development is still ongoing ;-) We > could probably get away with an extra tool that worked out compilation > order for us though. There is a distinct difference between development compiler and target compiler. Many project use the same compiler for both, but we all must recognize that this does not need to be the case. Say I use compiler X for development and target execution. Compiler X does not provide an ASIS interface. I find that I need to write some ASIS tools to do various things. I find compiler Y which supports ASIS. I use compiler Y on the same source simply to run the ASIS queries. If your doing Ada 95, GNAT is free and fully supports ASIS. > > Ralph. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-24 0:00 ` Samuel T. Harris @ 2000-03-24 0:00 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-03-24 0:00 UTC (permalink / raw) In article <38DBBD73.61A5F5E4@Raytheon.com>, "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote: > Not all compiler use DIANA trees In fact I think the *only* compiler that uses DIANA trees now is Rational, isn't that the case? I think the old Systeam compiler used DIANA too, but basically DIANA failed completely in its original mission as an implementation independent representation format. ASIS was the technology that developed out of DIANA, basically it provides a more appropriate abstract layer which can be applied to a wide variety of intermediate strucures, and is thus more appropriate for achieving compiler indepedence. DIANA prescribes a number of important choices in a compiler, and many Ada compiler designers have felt that it was simply not a desirable choice. That of course is the kind of thing which competition in the market place should determine (rather than an external standard), which is why ASIS has succeeded where DIANA failed (as a common intermediate language, I am not saying that it is not possible to use DIANA in an Ada 95 compiler, since obviously the Rational technology is a counter example). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-20 0:00 Pragma Inline and its Effects of Compilation Dependencies Ralph Corderoy 2000-03-21 0:00 ` Robert Dewar 2000-03-21 0:00 ` Samuel T. Harris @ 2000-03-22 0:00 ` Robert Dewar 2000-03-23 0:00 ` Ralph Corderoy 2 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 2000-03-22 0:00 UTC (permalink / raw) In article <8b64ul$jov$1@inputplus.demon.co.uk>, ralph@inputplus.demon.co.uk (Ralph Corderoy) wrote: > I've read a little about gnat's gnatmake and how the compiler > doesn't follow the normal library implementation and instead > uses the source files coupled with ALI files. No, the compiler does NOT use ALI files, it only uses source files. This is extremely crucial, since the set of ALI files would be affected by the order of compilation. > Does that mean in practice it copes > correctly with inline dependencies, including when they're in separates? Yes, inlines are handled in all cases, separates make no difference to this at all. > The manual seemed to suggest it didn't consider source outside > the current library. That's confused, GNAT has no notion of library in that sense. The only requirement is that all sources be available to the compilation process. > That wouldn't help in my case. Consider if foo was > being built into a separate Ada library from bar; I alter foo.y.ada and > build locally there. I then want to move to bar's library and find it > is out of date. This kind of scenario is handled in complete generality by gnatmake and related tools, and the correct minimal set of sources is always identified correctly and compiled, regardless of changing dependences. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-22 0:00 ` Robert Dewar @ 2000-03-23 0:00 ` Ralph Corderoy 2000-03-23 0:00 ` Robert Dewar 0 siblings, 1 reply; 22+ messages in thread From: Ralph Corderoy @ 2000-03-23 0:00 UTC (permalink / raw) Hi Robert, > > The manual seemed to suggest it didn't consider source outside the > > current library. > > That's confused, GNAT has no notion of library in that sense. The > only requirement is that all sources be available to the compilation > process. OK, thanks. And having several thousand source files spread over dozens of directories doesn't make this break down I guess. Ralph. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Pragma Inline and its Effects of Compilation Dependencies. 2000-03-23 0:00 ` Ralph Corderoy @ 2000-03-23 0:00 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-03-23 0:00 UTC (permalink / raw) In article <8bd8d3$76s$1@inputplus.demon.co.uk>, ralph@inputplus.demon.co.uk (Ralph Corderoy) wrote: > Hi Robert, > > > > The manual seemed to suggest it didn't consider source outside the > > > current library. > > > > That's confused, GNAT has no notion of library in that sense. The > > only requirement is that all sources be available to the compilation > > process. > > OK, thanks. And having several thousand source files spread over > dozens of directories doesn't make this break down I guess. There are many ways of handling such a structure. One useful option is gnatmake -i, which compiles everything in place, putting new objects wherever the old ones were found, so that once you have everything where you want it, gnatmake automatically maintains this structure. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2000-03-24 0:00 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-20 0:00 Pragma Inline and its Effects of Compilation Dependencies Ralph Corderoy 2000-03-21 0:00 ` Robert Dewar 2000-03-21 0:00 ` Paul Graham 2000-03-21 0:00 ` Gautier 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Larry Kilgallen 2000-03-22 0:00 ` Ted Dennison 2000-03-22 0:00 ` Robert Dewar 2000-03-22 0:00 ` Larry Kilgallen 2000-03-22 0:00 ` Wes Groleau 2000-03-22 0:00 ` Robert A Duff 2000-03-22 0:00 ` Ken Garlington 2000-03-23 0:00 ` Ralph Corderoy 2000-03-23 0:00 ` Robert Dewar 2000-03-24 0:00 ` Robert A Duff 2000-03-21 0:00 ` Samuel T. Harris 2000-03-23 0:00 ` Ralph Corderoy 2000-03-24 0:00 ` Samuel T. Harris 2000-03-24 0:00 ` Robert Dewar 2000-03-22 0:00 ` Robert Dewar 2000-03-23 0:00 ` Ralph Corderoy 2000-03-23 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox