I'm displeased with someone's workaround for decisions made by
the (rather weak) inliner in gcc 3.[123]. In particular, that
someone doesn't understand all of the implications of always_inline.
This attribute was invented to handle certain cases in <altivec.h>
and <xmmintrin.h> that contain assembly instructions that require
constant arguments. These instructions *cannot* be emitted unless
the user of the function supplies a constant. Which, under normal
usage situations is not a problem -- when the user doesn't give us
a constant, we error and that's the end. But it does mean that
the compiler is specifically *not* allowed to emit an out-of-line
copy of such a function, since there is in fact no way to legally
do so.
In the Alpha port I have a number of places in which I have
functions that I would like inlined when they are called directly,
but I also need to take their address so that they may be registered
as part of a dispatch vector for the specific machine model.
This scheme fails because my functions got marked always_inline
behind my back, which means they didn't get emitted in the right
place.
Rather than fight the unwinnable fight to remove this hack entirely,
may I ask that at least one of the different names for inline, e.g.
__inline__, be left un-touched so that it can be used by those that
understand what the keyword is supposed to mean?
Of course, there does not exist a variant that isn't used by all
sorts of random code, so presumably all existing occurences would
have to get renamed to plan "inline" in order to keep people happy...
r~