On 7/19/07, tbp <[EMAIL PROTECTED]> wrote:
I have that usual heavy duty 3 fp components class that needs to be
reasonably efficient and takes this form for g++
struct vec_t {
float x,y,z;
const float &operator()(const uint_t i) const { return *(&x + i); }
float &operator()
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> 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 { flo
On Thu, 19 Jul 2007, tbp wrote:
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> 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
lea
On 19 July 2007 14:08, tbp wrote:
> I have that usual heavy duty 3 fp components class that needs to be
> reasonably efficient and takes this form for g++
> struct vec_t {
> float x,y,z;
> const float &operator()(const uint_t i) const { return *(&x + i); }
> float &operator()(con
On 7/19/07, tbp <[EMAIL PROTECTED]> wrote:
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> 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
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
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?
By essence they're hard to trigger in small testcases (that's not
wher
On 7/19/07, Dave Korn <[EMAIL PROTECTED]> wrote:
Bogus codegen is the inevitable result of bogus code. Garbage in, garbage
out.
BTW, the const indexing is completely undefined too.
That's the kind of answer i'd get from gcc-help and at that point i'd
be none wiser because i already know th
On 19 July 2007 20:38, tbp wrote:
> On 7/19/07, Dave Korn wrote:
>> Bogus codegen is the inevitable result of bogus code. Garbage in,
>> garbage out.
>>
>> BTW, the const indexing is completely undefined too.
> That's the kind of answer i'd get from gcc-help and at that point i'd
> be none
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
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?
There's many issues for all alternatives and i'm not qualified to
pinp
On 7/21/07, tbp <[EMAIL PROTECTED]> wrote:
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> 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?
There's many issues fo
On 7/24/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (>4 members), aliasing will
make a difference possibly, m
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (>4 members), aliasing will
make a difference possibly, making the array variant slower. Any union
variant is e
On 7/25/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> For performance small arrays should be the same as individual members
> (I can see the annoying fact that initialization is a headache - this has
> annoyed me as well). For larger arrays (>4 members), aliasing will
> make a difference possi
13 matches
Mail list logo
