Altivec strangeness?

Altivec strangeness?

[Daniel Egger]

Hija,

I'm fooling around with altivec and tried to convert my sources, thereby
I discovered the following strangeness:

#include <altivec.h>

static const vector signed short test = {1, 2, 3, 4, 5, 6, 7, 8};

static const vector signed short test2[2] =
{
    {1, 2, 3, 4, 5, 6, 7, 8},
    {1, 2, 3, 4, 5, 6, 7, 8}
};

static const vector signed short test3[2] =
{
    {(1, 2, 3, 4, 5, 6, 7, 8)},
    {(1, 2, 3, 4, 5, 6, 7, 8)}
};

gives:

test.c:7: warning: braces around scalar initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:7: warning: excess elements in vector initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:7: warning: excess elements in vector initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:7: warning: excess elements in vector initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:7: warning: excess elements in vector initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:7: warning: excess elements in vector initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:7: warning: excess elements in vector initializer
test.c:7: warning: (near initialization for `test2[0]')
test.c:8: warning: braces around scalar initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:8: warning: excess elements in vector initializer
test.c:8: warning: (near initialization for `test2[1]')
test.c:13: warning: braces around scalar initializer
test.c:13: warning: (near initialization for `test3[0]')
test.c:14: warning: braces around scalar initializer
test.c:14: warning: (near initialization for `test3[1]')

I believe test2 should work and I added test3 only to try
whether the warning goes away.

And further: How do I initialize a vector with the same value
to all elements? 
static const vector signed short foo = {1};
gives me {1, 0, 0, 0, 0, 0, 0, 0, 0} as result which is loaded
from memory whilst a vector splat might be more efficient here.

-- 
Servus,
       Daniel

Re: Altivec strangeness?

[Aldy Hernandez]

On Saturday, February 23, 2002, at 02:55  AM, Daniel Egger wrote:

> Hija,
>
> I'm fooling around with altivec and tried to convert my sources, thereby
> I discovered the following strangeness:
>
> #include <altivec.h>
>
> static const vector signed short test = {1, 2, 3, 4, 5, 6, 7, 8};

the above should be:

blah vector signed short test = (vector signed short){1,2,3,etc};

the altivec specs mention that you need a cast.  this is a context
sensitivity issue.  gcc can't know what {1,2,3,etc} is.  perhaps
the compiler you are using now uses context magic to figure out
what type the initializer is... gcc won't do that.

> And further: How do I initialize a vector with the same value
> to all elements?
> static const vector signed short foo = {1};

1,1,1,1,1,1,1,1 ;-)

seriously, the (1) nonsense will work with jason merrill's patches
but you'll have to apply those on your own.  but please don't.
the hope is to wean people off of the parentheses nonsense-- alongside
that, wean them off of the {1} stuff.  that just goes against
C syntax.

> gives me {1, 0, 0, 0, 0, 0, 0, 0, 0} as result which is loaded
> from memory whilst a vector splat might be more efficient here.

warning will robbinson!  the vector initializer code is not, ahem,
efficient.  it will need to be rewritted with vector constants to
yield better code, perhaps for 3.2.  but imo, that's not a big issue
because you never initialize a vector inside a loop.

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: Altivec strangeness?

[Daniel Egger]

Am Fre, 2002-02-22 um 23.35 schrieb Aldy Hernandez:

> the above should be:
> blah vector signed short test = (vector signed short){1,2,3,etc};

I got it. It's like the Motorola crazyness but with {}'s instead of
parens.
 
> the altivec specs mention that you need a cast.  this is a context
> sensitivity issue.  gcc can't know what {1,2,3,etc} is.  perhaps
> the compiler you are using now uses context magic to figure out
> what type the initializer is... gcc won't do that.

Doesn't make sense to me. Isn't the compiler assuming that the rvalue
is of the same time as the lvalue of the assignment? Seems not, but why?
in 
vector signed short test = rhs;
for example it should be pretty clear that the right hand side is a 
vector signed short and if it's not the compiler should bail out with an
error.

> seriously, the (1) nonsense will work with jason merrill's patches
> but you'll have to apply those on your own.  but please don't.
> the hope is to wean people off of the parentheses nonsense-- alongside
> that, wean them off of the {1} stuff.  that just goes against
> C syntax.

It does, but how we one be able to represent a constant vector of
common values without typing them all? This is 
a) nasty because it requires a lot of typing.
b) not the fastest way because it will take memory and be loaded into
   memory while splatting might be faster and schedule better.

> warning will robbinson!  the vector initializer code is not, ahem,
> efficient. 

I noticed that. :)

> it will need to be rewritted with vector constants to
> yield better code, perhaps for 3.2.  but imo, that's not a big issue
> because you never initialize a vector inside a loop.

Why shouldn't I? If it's not invariant I might make sense to do that in
a loop for example to get working data into a vector register.

-- 
Servus,
       Daniel

Re: Altivec strangeness?

[Aldy Hernandez]

>> that, wean them off of the {1} stuff.  that just goes against
>> C syntax.
>
> It does, but how we one be able to represent a constant vector of
> common values without typing them all? This is

there's no precedence in C for this.  it goes against the grain.

> a) nasty because it requires a lot of typing.

declare a macro:

	#define VSHORT_1S ((vector short int){1,1,1,1,1,1,1,1})

> b) not the fastest way because it will take memory and be loaded into
>    memory while splatting might be faster and schedule better.

as i have mentioned before, the vector initializers generate pretty
bad code, but that will be remedied when, in 3.2, i rewrite them
to use the vector constant infrastructure.  right now, they just
get initialized as arrays, which is less than optimal.

in the code's defense, how many times do you initialize a given
vector in a function?  once!  it's not like it's going to drag
performance down.  and if you have it in a loop, it's probably
invariant, so move it out of it.

let's concentrate on getting the bugs ironed out of the current
implementation, and then we can tackle code quality issues.

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: Altivec strangeness?

[Daniel Egger]

Am Mon, 2002-02-25 um 00.26 schrieb Aldy Hernandez:

> > a) nasty because it requires a lot of typing.
> declare a macro:
> 	#define VSHORT_1S ((vector short int){1,1,1,1,1,1,1,1})

That's no much shorter than
const vector short shortones = (vector short int){1,1,1,1,1,1,1,1};
globally defined.
 
> as i have mentioned before, the vector initializers generate pretty
> bad code, but that will be remedied when, in 3.2, i rewrite them
> to use the vector constant infrastructure.  right now, they just
> get initialized as arrays, which is less than optimal.

Indeed.
 
> in the code's defense, how many times do you initialize a given
> vector in a function?  once!  it's not like it's going to drag
> performance down.

No, not in my case. I've small functions which have an generic
implementation but can be replaced by vectorised code. A profile
of a short run of the application will look like that:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 11.83      0.68     0.68    99864     6.81     9.81  synth_filter
 11.48      1.34     0.66  2105726     0.31     0.31  put_pixels_altivec
 11.48      2.00     0.66  1436416     0.46     0.46  j_rev_dct_altivec

For a function which is called a few million times per second runtime
it makes a lot of difference whether a constant vector is loaded
from memory whereby extra code is required to setup the base address
for the vector load or the vector simply get splatted into a vector
register which uses less memory, less opcodes and is likely happen
in the same amount of cpu cycles.

This is an example of assembly output produced by gcc 3.1:
	.align 2
        .globl put_pixels_clamped_altivec
        .type   put_pixels_clamped_altivec,@function
put_pixels_clamped_altivec:
        lis %r0,0x108
        lis %r9,zeros@ha
        ori %r0,%r0,16
        la %r9,zeros@l(%r9)
        dst %r3,%r0,0
        lvx %v13,0,%r9
        li %r0,8
        li %r11,0
        mtctr %r0
        li %r9,4
.L53:
        lvx %v0,0,%r3
        addi %r3,%r3,16
        vpkshus %v0,%v0,%v13
        vspltw %v1,%v0,1
        vspltw %v0,%v0,0
        stvewx %v0,%r11,%r4
        stvewx %v1,%r9,%r4
        add %r4,%r4,%r5
        bdnz .L53
        blr


As you can see it takes an additional lis, la to get the address
for the vector load. The inner loop is executed 8 times BTW.

> and if you have it in a loop, it's probably invariant, so move it out of it.

You bet on it. :)

> let's concentrate on getting the bugs ironed out of the current
> implementation, and then we can tackle code quality issues.

I hope you don't mind if I fool a bit around with code generation
now. :)
 
-- 
Servus,
       Daniel

Re: Altivec strangeness?

[Aldy Hernandez]

> That's no much shorter than
> const vector short shortones = (vector short int){1,1,1,1,1,1,1,1};
> globally defined.

sounds good.

> For a function which is called a few million times per second runtime
> it makes a lot of difference whether a constant vector is loaded

load from "shortones" then.  it will be less worse.

> I hope you don't mind if I fool a bit around with code generation
> now. :)

not at all!  be my guest.

and keep the bug reports coming.

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: Altivec strangeness?

[Jakub Jelinek]

On Fri, Feb 22, 2002 at 04:55:00PM +0100, Daniel Egger wrote:
> I believe test2 should work and I added test3 only to try
> whether the warning goes away.
> 
> And further: How do I initialize a vector with the same value
> to all elements? 
> static const vector signed short foo = {1};
> gives me {1, 0, 0, 0, 0, 0, 0, 0, 0} as result which is loaded
> from memory whilst a vector splat might be more efficient here.

If you just want to save typing, with recent Aldy's patch:

static const vector signed short foo = { [0 ... 7] = 1 };

should work (but you have to know how many elements it has, and it
is a GNU extension).
The result will be the same as { 1, 1, 1, 1, 1, 1, 1, 1 } though,
so it will load the constant from memory as well.

	Jakub

Re: Altivec strangeness?

[Daniel Egger]

Am Mon, 2002-02-25 um 10.49 schrieb Jakub Jelinek:

> If you just want to save typing, with recent Aldy's patch: 
> static const vector signed short foo = { [0 ... 7] = 1 };

Sounds good to me. It's much better to hack and easier to read.
 
> should work (but you have to know how many elements it has, and it
> is a GNU extension).

That's not an issue because
a) I do know the number of elements
b) Code using the gcc altivec extension can be compiled only with gcc
   except for the complete bogus Motorola gcc.

> The result will be the same as { 1, 1, 1, 1, 1, 1, 1, 1 } though,
> so it will load the constant from memory as well.

For now it's okay, needs to be fixed sooner or later though.
 
-- 
Servus,
       Daniel

Re: Altivec strangeness?

[Daniel Egger]

Am Mon, 2002-02-25 um 03.13 schrieb Aldy Hernandez:

> > For a function which is called a few million times per second runtime
> > it makes a lot of difference whether a constant vector is loaded
 
> load from "shortones" then.  it will be less worse.

Sorry, can't follow. Why should it make a difference, cpucycle-wise?
 
> and keep the bug reports coming.

There's much to report I fear.... :/
 
-- 
Servus,
       Daniel

Re: Altivec strangeness?

[Aldy Hernandez]

>>>>> "Daniel" == Daniel Egger <degger@fhm.edu> writes:

 >> and keep the bug reports coming.

 > There's much to report I fear.... :/

"waterfall approaching?"

"Yup."

"sharp rocks at the bottom?"

"most likely".

..."bring it on!"