AltiVec too pedantic about type qualifiers [UPDATE]

AltiVec too pedantic about type qualifiers [UPDATE]

[Daniel Egger]

Hija,

I further discovered that my words in the last mail are not
only partially valid for a "vector shift left".

#include <altivec.h>

void test (const char *test)
{
  vector signed char vec;

  vec = vec_lvsl (0, test);
}

fails as well while in real world code it works without casting and
produces exactly 1 warning, here's an excerpt from an example that
does compile.

static void
put_no_rnd_pixels_x2_altivec (UINT8 *block, const UINT8 *pixels, int line_size, int h)
{
  vector unsigned char align, hi, lo, shiftshift, shift, shifted;
  vector unsigned char output;
  vector unsigned short result, sum;
  vector unsigned short big, bigshifted;

  /* Since the stride is a multiple of 16 the shift will be always the same */
  shift = vec_lvsl (0, pixels);
  shiftshift = vec_adds (shift, cones);

  do
    {
      /* Load next line */
      hi = vec_ld (0, (UINT8 *) pixels);
      lo = vec_ld (16, (UINT8 *) pixels);
      align = vec_perm (hi, lo, shift);

      /* Shifted row */
      shifted = vec_perm (hi, lo, shiftshift);

      (vector unsigned char) big = vec_mergeh (zeros, align);
      (vector unsigned char) bigshifted = vec_mergeh (zeros, shifted);

      sum = vec_adds (big, bigshifted);
      result = vec_sr (sum, sones);
      
      output = vec_packsu (result, result);
      (vector unsigned int) lo = vec_splat ((vector unsigned int) output, 0);
      (vector unsigned int) hi = vec_splat ((vector unsigned int) output, 1);
      vec_ste ((vector unsigned int) lo, 0, (unsigned int *) block);
      vec_ste ((vector unsigned int) hi, 4, (unsigned int *) block);

      pixels += line_size;
      block += line_size;
    }
  while (--h);
}

-- 
Servus,
       Daniel (who's about to go nuts because of all the casting)

Re: AltiVec too pedantic about type qualifiers [UPDATE]

[Aldy Hernandez]

On Monday, February 25, 2002, at 10:55  AM, Daniel Egger wrote:

> Hija,
>
> I further discovered that my words in the last mail are not
> only partially valid for a "vector shift left".
>
> #include <altivec.h>
>
> void test (const char *test)
> {
>   vector signed char vec;
>
>   vec = vec_lvsl (0, test);
> }

there are a few things wrong here:

first, vec_lvsl accepts "char *" not "const char *", so you'll
have to cast.

second, and most importantly, the altivec specs say that
vec_lvsl() returns a "vector unsigned char" for any of its
variants... so you'll have to cast the return to "vector signed
char".  gcc will not do the conversion for you like with
scalars of signed int/unsigned int.

i had a patch to allow copying within vector unsigned and
vector signed automatically, but it was vetoed for
"safety" reasons.

aldy

Re: AltiVec too pedantic about type qualifiers [UPDATE]

[Daniel Egger]

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

> first, vec_lvsl accepts "char *" not "const char *", so you'll
> have to cast.

That's about the most annoying thing. What's wrong about loading 
from a constant address?

> second, and most importantly, the altivec specs say that
> vec_lvsl() returns a "vector unsigned char" for any of its
> variants... so you'll have to cast the return to "vector signed
> char".  gcc will not do the conversion for you like with
> scalars of signed int/unsigned int.

Yes, that was just a cut-n-pasto in the example.
 
-- 
Servus,
       Daniel

builtin_types_compatible_p and const

[Aldy Hernandez]

On Tuesday, February 26, 2002, at 12:38  AM, Daniel Egger wrote:

> Am Mon, 2002-02-25 um 03.03 schrieb Aldy Hernandez:
>
>> first, vec_lvsl accepts "char *" not "const char *", so you'll
>> have to cast.
>
> That's about the most annoying thing. What's wrong about loading
> from a constant address?

i agree, let's summon the expert again...

joseph, i agree with daniel.  the code below should compile, but
x and y are not compatible according to the builtin.  are there
any objections to making a patch to fix this?

const char *x;
char *y;
int foo[__builtin_types_compatible_p (__typeof(x), __typeof(y)) == 1 ? 
1 : -1];

Re: builtin_types_compatible_p and const

[Daniel Jacobowitz]

On Tue, Feb 26, 2002 at 10:45:04AM +1100, Aldy Hernandez wrote:
> 
> On Tuesday, February 26, 2002, at 12:38  AM, Daniel Egger wrote:
> 
> >Am Mon, 2002-02-25 um 03.03 schrieb Aldy Hernandez:
> >
> >>first, vec_lvsl accepts "char *" not "const char *", so you'll
> >>have to cast.
> >
> >That's about the most annoying thing. What's wrong about loading
> >from a constant address?
> 
> i agree, let's summon the expert again...
> 
> joseph, i agree with daniel.  the code below should compile, but
> x and y are not compatible according to the builtin.  are there
> any objections to making a patch to fix this?
> 
> const char *x;
> char *y;
> int foo[__builtin_types_compatible_p (__typeof(x), __typeof(y)) == 1 ? 
> 1 : -1];

Two things:
 - at that point, you're not really dealing with type compatibility any
  more.  They aren't compatible as I understand it; but under default
  promotions they can be.

 - You then need to distinguish the arguments to
  __builtin_close_enough_p or whatever it becomes.
    __builtin_close_enough_p (const char *, char *)
   may be OK, but what about:
    __builtin_close_enough_p (char *, const char *)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: builtin_types_compatible_p and const

[Joseph S. Myers]

On Tue, 26 Feb 2002, Aldy Hernandez wrote:

> >> first, vec_lvsl accepts "char *" not "const char *", so you'll
> >> have to cast.
> >
> > That's about the most annoying thing. What's wrong about loading
> > from a constant address?
> 
> i agree, let's summon the expert again...
> 
> joseph, i agree with daniel.  the code below should compile, but
> x and y are not compatible according to the builtin.  are there
> any objections to making a patch to fix this?
> 
> const char *x;
> char *y;
> int foo[__builtin_types_compatible_p (__typeof(x), __typeof(y)) == 1 ? 
> 1 : -1];

If vec_lvsl accepts "char *" rather than "const char *", presumably it
modifies what's pointed to by its argument (else why wasn't it specified
to use const, unless the interface predates ANSI C89)?

Again, check *x and *y, or explicitly enumerate the variants in the
header.  Or arrange for some built-in function to check for assignability
(which is not the same as compatibility) - in this case, that the target
type of the argument has fewer qualifiers than that of the formal
parameter, so you avoid allowing volatile there - but if you're passing
const, then vec_lvsl should be prototyped to accept it.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: builtin_types_compatible_p and const

[Daniel Egger]

Am Die, 2002-02-26 um 10.24 schrieb Joseph S. Myers:

> If vec_lvsl accepts "char *" rather than "const char *", presumably it
> modifies what's pointed to by its argument (else why wasn't it specified
> to use const, unless the interface predates ANSI C89)?

No it doesn't. I simply takes the given address & 0xF and generates
a permutation vector that can be used to align data not aligned 
on a 16byte boundary.

On a side note: The AltiVec Programming Interface Manual stats on
side 100:

"d = vec_lvsl (a, b)"

and further

"The b type may also be a pointer to a const- or volatile-qualified
type"

and to backup my complaint about not being able to vec_ld from
const types:

"d = vec_ld (a, b)" 

[...]

"The b type may also be a pointer to a const-qualified type"
 
-- 
Servus,
       Daniel