Re: g++ 4.3, troubles with C++ indexing idioms

[Joel Dice <dicej at mailsnare dot net>]

On Thu, 19 Jul 2007, tbp wrote:

> On 7/19/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> > Well, I always used the array variant, but you should be able to do
> [snip]
> > if you need to (why does the array form not work for you?)
> Because if you bench in some non trivial program, on x86/x86-64 at
> least, those variations (struct { float x,y,z; }, struct { float f[3];
> } and some additional union layer) the last 2 consistently come out as
> slower. In the array case addressing seems to be the main issue
> (redundant scaling etc...); for the union variant, it's less clear but
> it seems it prohibits some copy/return value optimizations.
> Plus gcc apparently likes (well, used to) very much the *(&x + i)
> idiom; all in all i had something to work with.

It's worth noting that C++ does not guarantee that (&y == &x + 1) in your 
example.  The compiler is allowed to insert in arbitrary amount of 
padding between the fields of a structure.  If it works, you got lucky.

> Now i'm seeing *some* stores indexed in this way vanish, array
> addressing is still as bad as it was, unions still get me some
> pessimization and using the memcpy idiom asks me to give up on the
> idea of an array acces operator altogether.
>
> So i'm asking, which is going to be fixed in the foreseeable future.