Re: stop using P_, __P in header files

[Ken Raeburn]

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