two-element struct performance (was: strict-aliasing and typedefs)

[Joe Buck <jbuck at synopsys dot com>]

On Thu, May 15, 2003 at 12:16:56AM +0200, Gabriel Dos Reis wrote:
> Joe Buck <jbuck@synopsys.com> writes:
> 
> | GCC does a decent job with one-element structs; its performance
> | quickly drops like a rock as soon as there are two elements.  Still,
> | there may well be some loss from using it.
> 
> Would that loss of performance be related to ABI issues (in single
> element case)? 

No, it has to do with premature commitment of structs to memory.  The only
way out is to be able to do more aggressive transformations on trees, to get
rid of structs that aren't needed.  For the one-element case, there are some
special-case tricks, which give us a nice (but misleading) Stepanov abstraction
penalty score.  Every object in the Stepanov benchmark has one element.

Actually there's another way out: be able to treat aggregates as scalars.  However,
it seems this isn't really needed for many of the cases that hurt C++ performance
(e.g. iterators with more than one element).

Take a look, for example, at the code generated for the following:

--------------------------------
struct complex {
    double re, im;
    complex(double r, double i) : re(r), im(i) {}
};

inline complex operator+(const complex& a, const complex& b) {
    return complex(a.re+b.re, a.im+b.im);
}

complex addone(const complex& arg) {
    return arg + complex(1,0);
}
------------------------------

It's pretty horrific, because gcc insists on making an actual RAM object for the
temporary struct (even for tree-ssa).

>From looking at the tree dumps on the tree-ssa branch, it would seem that a
decent copy propagation pass could propagate the 1.0 and 0.0 values through,
leaving the temporary struct as a dead object.