altivec very broken

altivec very broken

[Aldy Hernandez]

hi daniel.

with your last set of patches it seems that altivec is completely
broken.  none of my sample *simple* programs work.

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);

}
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);

} 
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))
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$ 

Re: altivec very broken

[Daniel Berlin]

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$
>

Re: altivec very broken

[Daniel Berlin]

On Sun, 9 Dec 2001, Daniel Berlin wrote:

> >
> > hotdog(){
> >         __builtin_altivec_vmadduwm (x, y);
> >
> > }
>
> Ditto the name of the function.
> Change it to vadduwm, and the problem goes away.

BTW, it's interesting to note that the use of vector_size makes the
generation of mem:SI instead of mem:V4SI for the globals go away.
No idea why.

>
>
> > 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.


Sorry, i've got this one wrong.
It actually fails the first constraint, because it finds that r3 is not a
V4SI mode register, and V4SI modes aren't allowed there.

It assigned r3 because of a combination of some bug thinking it was okay
(somewhere we've got a missing check), and not using abi=altivec.

If you use -mabi=altivec, it'll assign an okay register, and the problem
goes away.
But the test wouldn't work anyway, since it'll actually generate teh
following rtl:

(insn 13 11 15 (set (reg:V4SI 79 v2)
        (mem/f:V4SI (reg/f:SI 116) [0 x+0 S16 A128])) -1 (nil)
    (nil))

(insn 15 13 16 (set (reg:V4SI 79 v2)
        (mem/f:V4SI (reg/f:SI 118) [0 y+0 S16 A128])) -1 (nil)
    (nil))


(call_insn 16 15 17 (parallel[
            (set (reg:SI 3 r3)
                (call (mem:SI (symbol_ref:SI
("__builtin_altivec_vmadduwm")) [0 S4 A32])
                    (const_int 0 [0x0])))
            (use (const_int 4 [0x4]))
            (clobber (scratch:SI))
        ] ) -1 (nil)
    (nil)
    (expr_list (use (reg:V4SI 79 v2))
        (expr_list (use (reg:V4SI 79 v2))
	    (nil))))

So maybe we aren't assigning argument passing registers right for
-mabi=altivec, either.

>
>
> > 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$
> >
>