This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Can GCC eliminate stores to a structure?

[ this response is to a message posted to gcc2 in May of '97 ]

Joe Buck <> writes:

> > | I was looking at how well GCC optimized references to structures and am
> > | wondering why it doesn't eliminate certain code.
> > Well, its a problem that GCC's internal abstration layer only recognizes
> > scalar (& complex) types.
> Unfortunately this deficiency imposes a high penalty for modern
> (STL-based) C++ programming styles, and means that the section of the
> gcc manual titled "An Inline Function is As Fast As a Macro" should have
> the footnote "unless there is a struct or class anywhere in the vicinity"
> added.  g++ risks being about three times as slow, or more, than compilers
> that do not have this blind spot (that struct == a position on the stack),
> judging by some bragging that Kuck and Associates have been doing lately.
> But I don't think the answer is to just add a type to the intermediate
> form specifying the size of a struct.  When a struct is automatic, there
> is no reason to constrain its layout; it can just be treated as a
> collection of values, which can be allocated and spilled independently,
> or spilled all at once, and only in the latter case would it need to be
> laid out according to the API of the machine.  It seems that the kind of
> RTL representation you'd want in this case is a list giving the types of
> the components.

Has any work been done in this area?  Last year, I implemented bounds
checking in gcc 2.7.2 by internally attaching lower and upper bounds
to pointers, then checking the pointer value against them at
dereference time.  The approach I took was to add a new rtl node type
CONCAT3 which holds the pointer triple (value, base, extent) by
analogy with CONCAT which holds real & imag parts of a complex.  I
also added a new machine mode to hold a triple of pointer mode words.
In hindsight, I wish I had designed something general as Joe describes
above, and rewritten complex (and bounded pointers) to use it.

In the interest of expediency, I will likely just port my 2.7.2
implementation to gcc-2.8.x.  After that, I'd like to rewrite.

I'd appreciate input that anyone might have about such a design.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]