This is the mail archive of the gcc@gcc.gnu.org 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 7/19/07, tbp <tbptbp@gmail.com> 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.

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.

Of course, if any then the array indexing variant is fixed. It would be nice to see a complete testcase with a pessimization, maybe you can file a bugreport about this?

Thanks,
Richard


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