Re: stop using P_, __P in header files

[Ken Raeburn <raeburn@raeburn.org>]

On Jul 5, 2010, at 13:31, Eli Zaretskii wrote:
> I'm not an expert, so I don't know.  Maybe someone else could chime
> in.  One issue that I'd be interested in is to know whether GCC uses
> this hint at some low optimization level,

From skimming some GCC code, it looks to me like either having the optimizer on, or using "register", may cause registers to be used.  (Specifically, if the optimizer is off and "register" is not used, then automatic variables appear to get stack slots unconditionally; otherwise, types and other restrictions permitting, they get "pseudo-registers" which may be assigned either registers or stack slots.)  So, for -O0, the register declarations might make a difference (I don't know how good the "stupid" allocator is for non-optimizing compiles), though my attitude is generally that for -O0, performance considerations don't matter much...  For -O1, I don't think the register declarations matter.

> FWIW, the ones I put in some code I wrote long ago were not naive at
> all.  And I don't think those we have in Emacs are naive, either.  But
> if these hints are not used, it doesn't really matter.

If we assume we don't have to tune the code for builds without decent optimization (including gcc -O0), I think at least some of them are kind of useless -- like any place where *all* the non-addressable variables are declared "register".  If that's a meaningful hint these days, the compiler's not doing a very good job.  Back in the '80s, when PCC was one of the more popular compilers around, you had to say "register" or everything would go in stack slots, even with the optimizer on.  And the first N register variables got assigned to a specific set of machine registers -- I recall working with VAX BSD kernel code that made use of known registers this way.  So for small functions, it made sense to make everything "register", when that was the common technology.

After a quick "grep register *.[chm]", the first one I pulled up was data.c:Fsetq_default, where all the automatic variables but "gcpro1" are "register", though the argument wasn't.  Next was data.c:Fneq, where both arguments are.  In data.c:Fash, all arguments and automatics are.  These really look like cases of PCC workarounds.  In dbusbind.c:Fdbus_method_return_internal, only "args" is; maybe that's possibly helpful, to some compiler somewhere; but shouldn't a decent optimizer figure it out from the large number of uses of the variable?

Ken