This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GCC 3.3 release criteria


> I think the inline keyword should be treated exactly in the 
> same terms as the register keyword.  That is, as a hint to
> the compiler.  As time goes by the inline keyword will become
> increasingly meaningless, since the compiler will be able to
> do a better job.  Forcing the compiler to respect inline
> regardless of the consequences is a mistake.

I couldn't disagree more. I think that treating the register
keyword as just a hint is a mistake too. Granted, some people
liberally sprinkle their code with register keywords, and for
those situations, having the compiler make intelligent choices
about what actually goes in a register is appropriate, iff
there are not suffucient available registers to satisfy the
user's whims.

Having register / inline behave the way the programmer expects
it to gives the programmer the power of choice. There are
legitimate cases where the programmer *NEEDS* a variable in
a certain register, perhaps because of some inline assembly,
perhaps because they know that a function being called a
few insns down expects things that way ... for any number of
reasons. inline is exactly the same. The programmer may well
have established that some code really *DOES* need to be
inline, to provoke certain processor semantics, for precise
setting up of caches for testing, for any number of reasons.
If the compiler tries to outsmart the programmer and take
the power of choice away from them, that's bad.

I really believe in freedom of choice for the coder, as much
as is practical. By all means, have the compiler be smart.
Have it inline things where the user didn't make an explicit
choice. But always try and give the user an out, because at
some point in time you are guaranteed to have a situation
where the user is much much more knowledgeable about the
exact insn pattern they want than the compiler can ever be.

If you really do want to make inline just a hint, may I
suggest that you still leave the user an "out". The UnixWare
compiler has a novell (I *SO* nearly typed Novel) solution.
They have a #pragma that controls how aggressive the
optimizer is around inline assembly.  I forget the exact
syntax but its something along the lines of #pragma asm
{no_optimization | partial_optimization | full_optimization}.
I forget what the exact semantic differences between
partial and full are, but I do know that full_optimization
means that all the inline assembly is subject to the global
optimizer. I think partial_optimization means it wont
optimize the functions the asm is used in, but will
optimize everything else. Something like that. But you see
the point. It gives the user control.

Some other such mechanism, perhaps even one more generic
than just inline asms, could be invented so that the Linux
folks can have their inlines, and others who care less can
have inline treated as a hint. Perhaps something along
the lines of #pragma always_inline (and by the same
token #pragma always_register) would be in order. Or even
a #pragma obey_modifier {register | inline | any_other_hint}
would do the trick.

Sorry for rambling. Give the power to the coder.

Kean


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]