Re: Target-specific pragmas

[Stan Shebs <shebs at apple dot com>]

"Joseph S. Myers" wrote:
> 
> On 20 Jun 2001, Geoff Keating wrote:
> 
> > > 1. How should target-specific pragmas be documented?  I notice that
> > > there are many existing pragmas in targets, but the manual does not
> > > seem to mention any of them anywhere.  Is this deliberate?
> >
> > Yes.  I believe that nearly all of the target-specific pragmas are
> > only for backwards compatibility with other compilers, and that
> > the preferred interface is to use __attribute__.
> 
> Every user-visible feature not in the language standards (and the handling
> of every case the standards say is implementation defined) should be
> documented in the manual.  If the pragma is just for compatibility, the
> manual should say so and refer the user to the documentation for the
> preferred alternative.

I agree with this.  The manual is supposed to describe things as they
are, not as we'd like them to be.

There is a very real situation to consider as well.  Suppose somebody
gets a pragma-using program that compiles with GCC.  How is he or she
going to know what the pragmas are supposed to do?  If the GCC manual
doesn't describe the pragmas, then we place our hapless maintainer in
the highly undesirable situation of having to buy a proprietary compiler
manual, just to know what GCC is supposed to do (note that reading GCC
sources is not the right answer, because the sources may not conform
to the behavior documented for the other compiler).

> > > 2. Some of our pragmas exist to provide per-function control over
> > > optimization levels and flag_writable_strings.  I vaguely remember
> > > some discussion over whether there ought to be some kind of fine
> > > grained control over flags via pragmas and/or attributes.  Is there
> > > a consensus on what to do here?
> >
> > The first, and trickiest part, is to work out what can actually be
> > changed, and when it can be changed.  I'm pretty sure you can't switch
> > between -O1 and -O0 in one compilation, for instance; I'm not
> > convinced that flag_writable_strings can be changed reliably either.
> 
> There's also again the matter of justifying why these pragmas are better
> than using separate source files.  It has been proposed that the
> compilation options should be included in the .o file - what would go
> there if they vary from function to function?  What about the information
> output by -fverbose-asm?

All good points.  This may be a non-issue, because I've been looking
in OS X sources for actual uses of the pragmas in question and haven't
found any so far.  (Found a couple new types of pragmas I'd never heard
of before, sigh, ifdefed out though.)

The only argument I know of for allowing per-function optimization
control is the theoretical one that the program's design shouldn't
be governed by limitations of the compiler - shouldn't have to split
up a file, and have to make statics into externs, etc, just because
the compiler is missing fine-grained control.  In practice I don't
think this comes up much, because optimization is supposed to be
mostly transparent to programmers, and if it's not transparent, the
the division of code into files is the least of one's problems. :-)

Stan