Re: altivec very broken

[Daniel Berlin <dan at cgsoftware dot com>]

On 9 Dec 2001, Aldy Hernandez wrote:

> hi daniel.
>
> with your last set of patches it seems that altivec is completely
> broken.  none of my sample *simple* programs work.
>
All of mine do.
I can also cause the errors you have without any of my patches, and had
seen them before, thus, know the cause already.


> they don't work with either amode() or vector_size() attributes.
>
> can you take a look at this?
>
> --
> Aldy Hernandez			E-mail: aldyh@redhat.com
> Professional Gypsy
> Red Hat, Inc.
>
> litecycle:/build/t2/gcc$ cat a.c
> int __attribute__((mode(V4SI))) x, y;
>
> hotdog(){
>         __builtin_altivec_vmadduwm (x, y);
>
> }

it's not vmadduwm, it's vadduwm. Because of this, it thinks it's taking
two ints, and can't for the life of it figure out how to move a V4SI mode
integer into an SI mode register. Thus, it aborts.

If you change it to vadduwm, you'll get a different abort, because the
global variable reference will be generated as:

(gdb) p debug_tree (arglist)
 <tree_list 0x300e3420
    value <var_decl 0x300e6280 x
        type <vector_type 0x3003e880 type <integer_type 0x30039780>
            V4SI
            size <integer_cst 0x3003d180 constant 128>
            unit size <integer_cst 0x3003d1c0 constant 16>
            align 128 symtab 0 alias set -1>
        used public static common defer-output SI file a.c line 1 size
<integer_cst 0x3003d180 128> unit size <integer_cst 0x3003d1c0 16>
        align 128
        (mem/f:SI (symbol_ref:SI ("x")) [0 x+0 S16 A128])
        chain <type_decl 0x30056f00 __g77_ulongint type <integer_type
0x30039600 long long unsigned int>
            VOID file <built-in> line 0
            align 1 chain <type_decl 0x30056e80 __g77_longint>>>
    chain <tree_list 0x300e3438
        value <var_decl 0x300e6300 y type <vector_type 0x3003e880>
            used public static common defer-output SI file a.c line 2 size
<integer_cst 0x3003d180 128> unit size <integer_cst 0x3003d1c0 16>
            align 128
            (mem/f:SI (symbol_ref:SI ("y")) [0 y+0 S16 A128]) chain
<var_decl 0x300e6280 x>>>>

Note the (mem/f:SI.

It can't figure out how to shove that into a v4si register, and thus,
aborts again.


In other words, neither of these are my fault.
:)
If you move the globals to locals, everything works okay again, and the
generated mem slots are (mem/f:V4SI

Make it stop using a mem:SI for whatever reason, and the problem goes
away.
>
litecycle:/build/t2/gcc$ ./cc1 a.c -maltivec -quiet
> a.c: In function `hotdog':
> a.c:4: Internal compiler error in emit_move_insn, at expr.c:2729
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> litecycle:/build/t2/gcc$
> litecycle:/build/t2/gcc$
> litecycle:/build/t2/gcc$ cat b.c
> #define vector __attribute__((vector_size(16)))
>
> vector int x, y;
>
> hotdog(){
>         __builtin_altivec_vmadduwm (x, y);
>
> }

Ditto the name of the function.
Change it to vadduwm, and the problem goes away.


> litecycle:/build/t2/gcc$ ./cc1 b.c -maltivec -quiet
> b.c: In function `hotdog':
> b.c:8: insn does not satisfy its constraints:
> (insn 34 31 15 (set (reg:V4SI 3 r3)
>         (mem:V4SI (reg:SI 10 r10) [0 S16 A32])) 524 {altivec_lvx_4si} (nil)
>     (nil))

You can tell the real problem here because it's attempting to assign an
integer register (reg:SI 10) to a vector memory slot.


> b.c:8: Internal compiler error in final_scan_insn, at final.c:2576
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> litecycle:/build/t2/gcc$
>