Re: Data Structure Reorganizing Optimizations

jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Wed, 2 Nov 1994 06:01:15 GMT

          From comp.compilers

Related articles
[6 earlier articles]
Data Structure Reorganizing Optimizations leichter@zodiac.rutgers.edu (1994-10-31)
Re: Data Structure Reorganizing Optimizations yuri@shimari.cmf.nrl.navy.mil (1994-10-31)
Re: Data Structure Reorganizing Optimizations ddg@cci.com (1994-10-31)
Re: Data Structure Reorganizing Optimizations amos@nsof.co.il (1994-11-01)
Re: Data Structure Reorganizing Optimizations pardo@cs.washington.edu (1994-10-31)
Re: Data Structure Reorganizing Optimizations fjh@munta.cs.mu.OZ.AU (1994-11-02)
Re: Data Structure Reorganizing Optimizations jeremy@sour.sw.oz.au (1994-11-02)
Re: Data Structure Reorganizing Optimizations prochak@cibadiag.com (1994-11-02)
Re: Data Structure Reorganizing Optimizations pardo@cs.washington.edu (1994-11-09)
Re: Data Structure Reorganizing Optimizations kendall@pot.East.Sun.COM (1994-11-05)
Re: Data Structure Reorganizing Optimizations praetorius@figs.enet.dec.com (1994-11-09)
Re: Data Structure Reorganizing Optimizations pjensen@csi.compuserve.com (1994-11-11)
Re: Data Structure Reorganizing Optimizations glew@ichips.intel.com (1994-11-13)
[7 later articles]
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Keywords: optimize, C
Organization: Softway Pty Limited
References: 94-10-108 94-10-223
Date: Wed, 2 Nov 1994 06:01:15 GMT

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
--


Post a followup to this message

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