CC/ASSUME=WHOLE_PROGRAM--what's a "well behaved library routine?"

[Galen Tackett]

I'm puzzled about this qualifier.

Citing the HP C V7.1 Users Guide, table 1-4 on page 1-22, /ASSUME=WHOLE_PROGRAM:


asserts to the compalier that except for "well-behaved library routines," the whole program consists only of the single object module being produced by this compilation."


Compare op. cit., p. 28:


The optimizations enabled by /ASSUME=WHOLE_PROGRAM include all those enabled by /ASSUME=NOPOINTER_TO_GLOBALS, and possibly additional optimizations as well.


Are these saying the same thing? I'm also a little curious what characterizes a "well behaved library routine," and what other optimizations the second citation might be referring (if any).

Can someone fill in the details?

Thanks,

Galen

[Steven Schweda]

I lack authority, but ...

I'd assume that a "library routine" is any
function supplied by HP, and that adding
"well behaved" to the description allows for
bugs or weird behavior unanticipated by the
fellow who wrote this description.

In general, I'd assume that it means that no
external function will be disturbing any
storage in unexpected ways. (For example, if
you pass an int or a double to an external
function, that function won't treat it as a
pointer, and write into some big array
starting there.)

[John Gillings · Accepted solution]

Galen,

A well behaved library routine is one that has no side effects on variables visible to the caller, other than parameters passed synchronously in or out via the argument list.

The compiler can therefore assume that no other variables are affected by a routine call, other than those in the argument list. This has important implications for optimizing accesses to variables by promoting them into registers. NOPOINTER_TO_GLOBALS is a more restricted assumption. WHOLE_PROGRAM means the compiler can assume there will be no other code that references any of the variables it knows about. So, for example, an outer level variable could be moved into a register for the entire program.

[Galen Tackett]

Steve and John,

Thank you both for these very informative replies. You confirm the general idea I had in mind but hadn't found a way to state clearly.


John,

I think I know the answer, but is "library routine" meant to imply "HP supplied" as well, or does it apply in general to any separately compiled routine that lives within the rules you stated? I assume it's the latter?

All,

Yesterday I did some very informal benchmarking of some of the Zlib compression library routines to see what difference some of these optimizations would make.

I don't have this information with me or I'd supply some details, but by using /PLUS_LIST_OPTIMIZE and a couple of other optimizations I saw quite a decrease in CPU time.

I'll hopefully find time to post some details later.

[John Gillings]

Galen,

>is "library routine" meant to imply
>"HP supplied" as well, or does it
>apply in general to any separately
>compiled routine that lives within
>the rules you stated? I assume it's
>the latter?

Correct. HP doesn't hold a monopoly on writing well behaved code ;-) As long as it's valid for the compiler to assume that a called routine is well behaved (as per my definition), then you're OK. Shareable image libraries that don't share storage may comply.

Note that the definition DOES NOT include all supplied HP routines! Simple example, a $QIO (not $QIOW) is not "well behaved" because the buffer and IOSB are written asynchronously after the routine has returned. If you call such a routine, it's up to you to ensure you've specified the appropriate "static" and/or "volatile" attributes to the affected variables in your source code.

As long as you've explicitly covered all cases that might violate compiler assumptions, you should be safe.

[Robert Gezelter]

Galen,

I concur with John.

Having worked with optimizers (at one point, I developed a code generator for a compiler, and a peephole optimizer phase for its output), the combination of a "non-well behaved library routine" and global optimization is particularly nightmarish.

Consider a paraemter variable which contains a pointer into another structure or variable. Then it is almost impossible to divine the true dependency of the library routine, or for that matter, the code calling the library routine.

When you enable global optimization, you give the compiler carte blanche to rearrange things as it sees fit. This can produce very significant improvements. However, if the information being used to understand the program is incorrect or incomplete, the results can be catastrophic.

- Bob Gezelter, http://www.rlgsc.com

[Galen Tackett]

All,

That pretty well covers the subject as far as I was interested in it.

Thanks!