register unions

Hank Dietz hankd at pur-ee.UUCP
Thu Feb 18 07:17:38 AEST 1988



According to K&R (page 193), a key constraint on objects of
storage class register is that:

	"the address-of operator & cannot be applied to them"

Now, I certainly admit that the original intent was simply to
give the compiler a hint as to which auto variables should be
placed in registers (if you've got 'em), but the lack of an
address for an object in C means that the object NAME HAS NO
ALIASES, and that is far more important to a good optimizing
or parallelizing compiler.

Consider code like:

	*p = b * c;
	a = b * c;

In this code, unless the compiler can prove that b and c
cannot be pointed-to by p, b * c is NOT a common
subexpression.  Proving that p can't point at b or c is,
however, very difficult under many circumstances --
particularly if b, c, and p are globals accessed in a
separately compiled module.  If b and c are declared as
register variables, then the address can't be taken, hence the
proof is given without need to examine separately compiled
modules, or anything else for that matter.  One might argue
that removing a common subexpression like b * c is not that
important an optimization, but similar constraints apply for
nearly all optimizations and in automatic parallelization.

In summary, for the most efficient and effective compilation,
register OUGHT TO MEAN "HAS NO ALIAS" and nothing else.  Hence,
it makes sense to say register anything -- any type, any
storage class (not just register implies auto, as K&R suggest)
-- and let the compiler assign registers as it sees fit.  In
fact, this is how at least a few optimizing C compilers treat
register declarations anyway.

More details as to treatment of register as a "noalias"-like
storage-class modifier appear in my PhD Thesis, "The
Refined-Language Approach to Compiling for Parallel
Supercomputers," Polytechnic University, Brooklyn NY.  I'm
currently an assistant prof. of EE at Purdue and can supply
reprints of the thesis or related materials directly, if you
prefer (so long as there are not too many of you).

					-Hank Dietz



More information about the Comp.lang.c mailing list