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]
Other format: [Raw text]

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

On Thu, 19 Jul 2007, tbp wrote:

On 7/19/07, Richard Guenther <> wrote:
Well, I always used the array variant, but you should be able to do
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.

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