Re: altivec amusement

Re: altivec amusement

[Aldy Hernandez]

[let's ask joseph about this one]

found the problem.

the moto specs are so vague... they're not helpful.  this
is a case of "eeech, you may be right, i may be right".


[snip]
	vector unsigned char high_products[256];
[snip]
	low  =  vec_ldl((int) *(inp++),high_products);

replace the high_products in the call to vec_ldl with:

	(vector unsigned char *)high_products

vec_ldl is expecting a "vector unsigned char *" in the second
argument, not a "vector unsigned char []".

joseph, it seems __builtin_types_equal differentiates between
	int foo[]
and
	int *foo

so what brad is trying to do won't work.

is __builtin_types_equal doing the right thing?

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

Re: altivec amusement

[Joseph S. Myers]

On Mon, 25 Feb 2002, Aldy Hernandez wrote:

> joseph, it seems __builtin_types_equal differentiates between
> 	int foo[]
> and
> 	int *foo
> 
> so what brad is trying to do won't work.
> 
> is __builtin_types_equal doing the right thing?

__builtin_types_compatible_p correctly distinguishes.  __typeof correctly
acts like sizeof in that the array-to-pointer and function-to-pointer
conversions do not apply to its argument.  (Of course the value that ends
up getting passed to the function does have those conversions applied.)

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

Re: altivec amusement

[Aldy Hernandez]

> __builtin_types_compatible_p correctly distinguishes.  __typeof 
> correctly
> acts like sizeof in that the array-to-pointer and function-to-pointer
> conversions do not apply to its argument.  (Of course the value that 
> ends

what i'm talking about is this:

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

brad wants the above to compile.

otherwise you can never pass an "int []" when we expect an
"int *" to an altivec macro/"overloaded function".

perhaps __builtin_types_compatible_p should return true for pointers
and array of the same underlying type (?)

> up getting passed to the function does have those conversions applied.)
>
> --
> Joseph S. Myers
> jsm28@cam.ac.uk
>
>
--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: altivec amusement

[Joseph S. Myers]

On Tue, 26 Feb 2002, Aldy Hernandez wrote:

> int x[5];
> int *y;
> int foo[__builtin_types_compatible_p (__typeof(x), __typeof(y)) == 1 ? 
> 1 : -1];
> 
> brad wants the above to compile.
> 
> otherwise you can never pass an "int []" when we expect an
> "int *" to an altivec macro/"overloaded function".

Perhaps then you should be using __typeof(*x) and __typeof(*y)?  (Or 
explicitly checking for array types.)

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

Re: altivec amusement

[Aldy Hernandez]

>>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:

 > I tried to port a code that uses AltiVec heavily, originally compiled with
 > CodeWarrior, to MacOS X using gcc-3.1 CVS.  I got an ICE (in emit_move_insn,
 > at expr.c:2748, if anyone's interested), but unfortunately I'll have to work
 > hard to see if I can come up with another test case, I can't just
 > post the code.

Reduce the testcase to the absolute bare reproducible minimum and
send me the .i.

 > What was amusing to me was to see the size of the .i file compared to the
 > c file: 20687949 bytes versus 12914 bytes.  It's going to be interesting
 > reading through the .i files that come with AltiVec test cases!

.i's are not meant for humans in altivec.

Aldy

Re: altivec amusement

[Richard Henderson]

On Fri, Feb 22, 2002 at 12:23:59AM -0500, Brad Lucier wrote:
> What was amusing to me was to see the size of the .i file compared to the
> .c file: 20687949 bytes versus 12914 bytes.

Yep.  The altivec spec is much more suited to c++ than c.


r~

altivec amusement

[Brad Lucier]

I tried to port a code that uses AltiVec heavily, originally compiled with
CodeWarrior, to MacOS X using gcc-3.1 CVS.  I got an ICE (in emit_move_insn,
at expr.c:2748, if anyone's interested), but unfortunately I'll have to work
hard to see if I can come up with another test case, I can't just post the code.

What was amusing to me was to see the size of the .i file compared to the
.c file: 20687949 bytes versus 12914 bytes.  It's going to be interesting
reading through the .i files that come with AltiVec test cases!

Brad