This is the mail archive of the
mailing list for the GCC project.
Re: Can GCC eliminate stores to a structure?
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: Can GCC eliminate stores to a structure?
- From: Greg McGary <gkm at eng dot ascend dot com>
- Date: 02 Mar 1998 17:55:00 -0700
- Cc: meissner at cygnus dot com (Mike Meissner), cagney at newmail dot tpgi dot com dot au, gcc2 at cygnus dot com, egcs at cygnus dot com
- References: <199705261655.JAA27436@atrus.synopsys.com>
[ this response is to a message posted to gcc2 in May of '97 ]
Joe Buck <email@example.com> 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.