Aliasing in ISO C (was: Re: Possible to write compiler to Java VM?)

Stavros Macrakis <macrakis@osf.org> wrote:
>Actually, there is a very direct bearing. There are several C
>features which make garbage collection difficult (although not
>impossible, as shown by the conservative collectors on the one hand
>and the interpretive C approach on the other), notably casts, untagged
>unions, and arrays without well-defined run-time lengths. There are
>also several features that make certain optimizations pretty much
>impossible, namely the possibility of almost arbitrary aliasing.


This is a fairly common misconception about C, IMHO.


The C standard is pretty clear in saying that in the following
function, it is permissible to avoid the second indirection and load
from *p1... assuming that you still have the value previously loaded
from *p1 in a register somewhere:


volatile int i;
volatile char ch1, ch2;


void foobar (char *p1, int *p2)
{
ch1 = *p1;
*p2 = i;
ch2 = *p1;
}


In other words, the C standard is pretty clear in saying that C only
supports aliasing of (i.e. multiple pointers to) ``compatible'' (which
in practice usually means ``identical'') types. In other cases, the C
standard makes few guarantees.


> Moreover, the low level of the language means that, although it is
> very easy to generate OK code for C, it is hard to optimize
> operations on higher-level structures, such as multidimensional
> arrays, and generate excellent code, especially on machines whose
> architecture is very different (e.g. distributed memory MIMD) from
> the flat byte address space, monoprocessor model implicit in C.


I would like to see the proof of this assertion. Once again, I believe
that the poster may be misreading the ISO C standard.


-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites -
--

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