Re: Languages that give "hints" to the compiler

Joe Hummel <jhummel@cy4.ICS.UCI.EDU> writes:
>some refs to work in this area? I'm interested in approaches for allowing
>the programmer to supply optimization information to the compiler.


wisej@acf4.nyu.edu (wisej) writes:
>Well, both C and C++ have the 'register' keyword for variable declaration,
>[as well as static and volatile]


Don't forget the `const' type qualifier... a highly under-rated (and,
in my opinion, under-used) feature of both C and C++.


In the absence of flow-analysis (either global, within the scope of some
block-local object, or interprocedural, in the case of file-scope objects)
the `const' qualifier can (I think) be used as an indication to the
compiler that the value of a given object is not expected to change, and
that this value, once loaded into a register, may be reused from that
register (without going back to memory again) wherever subsequent
references to the same object appear.


Now to tell the truth, I know of no C or C++ compilers that currently make
use of const qualification in this way, but I keep hoping. (If anyone
else knows of compilers that *do* use const qualification in the manner
I've described, please let me know.) Evidence of my hope may be seen
frequently in my own (recent) code, which is littered with stuff with
looks roughly like the following (for example):


{
register unsigned const table_len = primary + overflow;
register int *const table = malloc (table_len * sizeof (int));
register int *const limit = &table[table_len];
register int *p;


/* Zero out the entire table. */


for (p = table; p < limit; p++)
*p = 0;


...
}


Note that even compilers that do absolutely NO flow-analysis *should* be
able to understand that the value of `limit' can be (and probably should
be) kept in a register for the duration of the loop (because it is constant).
Thus, checking for loop termination (in that case of the code shown above)
*should* involve zero memory accesses... at least on machines where enough
registers are available.


Contrast this with the effects of a similar loop, written in a more
traditional way, and fed to a compiler that doesn't understand that
`const' means that the value doesn't change:


/* Zero out the entire table. */


for (p = table; p < &table[table_len]; p++)
*p = 0;


In this case, the check for loop termination would involve first loading
the current value of `table_len' into a register (well... on a RISC
machine anyway) and then multiplying that by sizeof(int), then loading the
current value of the pointer `table', and then (finally) adding these two
values (i.e. base and offset) together.


Quite a contrast, eh? Zero instructions versus two loads, a multiply, and
an add.


The really beautiful thing about `const' (in C and C++) is that intelligent
compilers *could* make use of this (const) information to produce better
code even in the absence of complicated and/or time-consuming flow-analysis.
Intelligent compilers *could* produce really fast code for references to
`const' qualified objects even during NON-OPTIMIZING compilation steps.


(As serious C/C++ implementors know however, there's a catch. Even if
a given object is declared `const' the compiler can only get away with
treating its value as a constant IF its address is NEVER taken anywhere
within its scope. Fortunately, in C at least, just having the object
declared also with the `register' keyword INSURES that the object's
address will never be taken, so in cases where some block-local object
is declared with BOTH `const' and `register', the compiler doesn't have
to have any great smarts to understand that the object's value may be
treated as being constant throughout its scope. Sadly, this is one of
the things that got broken in C++. In C++, unlike C, things declared
as `register' *may* have their addresses taken, so compilers for C++
have to first look at the entire scope of a given object... and make
sure that it doesn't have it's address taken anywhere therein... before
they can treat a `const' object as being constant. And even then, there
are some exceptions involving class-type objects. But I digress.)


--


-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -
--

Return to the comp.compilers page.
Search the comp.compilers archives again.