Re: Data Structure Reorganizing Optimizations

pardo@cs.washington.edu (David Keppel) writes:
>Structure *reordering* optimizations would break lots of C code because
>the C standard guarantees the *order* of structure elements. However,
>much of the code I've seen that relies on structure order also relies
>on structure *padding* (offsets) that the standard does not define.
>Technically, such code is already broken.


One of the most common structure member order assumption is the "struct hack"
(that is, structs of the form:
struct foo {
char random;
int len;
char data[1]; /* This is the start of a longer array */
};
).


Whether this form of structure is valid C is a subject of much (and
repeated) debate in comp.std.c, but it certainly doesn't depend on
the alignment of any of its members, but reorganizing it would
certainly break it.


>As optimizers improve, this code is going to fail more and more often.


Why would structure padding change with optimisation? Changing
structure shape because of optimisation level would be unmanagable
if you are trying to bind with libraries and operating systems.
Is there a need to extend the language so that "interface structures"
are obviously different from "random aggregate data structures"?


While the C standard doesn't enforce any particular structure layout
or conventions, ABIs for architectures/systems do, and all compilers
would be expected to not only be compliant with C, but also the
ABI of their environment.


Could a compiler look at the scope of a type definition to determine
if it can be the subject of invasive optimisations (which could
perhaps be done compilers conforming to the current standard)? This
way, if a type is proveably local to a module a compiler could
apply any optimisations it likes to the shape of the structure, so
long its "as if" the normal rules were being followed.


J
--

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