------- Comment #5 from steven at gcc dot gnu dot org 2010-07-18 17:21 -------
It looks like a store is scheduled wrong.
Slightly reduced test case:
---------------------- 8< --------------------#define vector
__attribute__((vector_size(16) ))
vector int f1(vector int t, int a)
{
((int*)&t)[1] = a;
return t;
}
int main(void)
{
vector int a = {0, 0, 0, 0};
vector int c = {0, 1, 0, 0};
vector int a0;
a0 = f1(a, 1);
if (memcmp (&a0, &c, sizeof(a0)))
__builtin_abort ();
return 0;
}
---------------------- 8< --------------------
Compiled at "-O2 -fno-inline -fpic" this will abort. The assembler output for
f1 is this:
6 .global f1#
7 .type f1#, @function
8 .proc f1#
9 f1:
10 .prologue
11 .body
12 .mmi
13 mov r15 = r12
14 nop 0
15 mov r14 = r12
16 ;;
17 .mmi
18 st8 [r15] = r32, 8
19 ;;
20 st8 [r15] = r33, -4
21 nop 0
22 .mii
23 ld8 r8 = [r14], 8
24 nop 0
25 ;;
26 nop 0
27 .mmb
28 ld8 r9 = [r14]
29 st4 [r15] = r34
30 br.ret.sptk.many b0
31 .endp f1#
The store on line 29 looked suspicious because the three stores (lines 18, 20,
and 29) are together in the unscheduled version (i.e. with
-fno-schedule-insns2, lines 15, 17, and 19):
6 .global f1#
7 .type f1#, @function
8 .proc f1#
9 f1:
10 .prologue
11 .body
12 mov r15 = r12
13 mov r14 = r12
14 ;;
15 st8 [r15] = r32, 8
16 ;;
17 st8 [r15] = r33, -4
18 ;;
19 st4 [r15] = r34
20 ld8 r8 = [r14], 8
21 ;;
22 ld8 r9 = [r14]
23 br.ret.sptk.many b0
24 ;;
25 .endp f1#
The abort goes away if I hack the assembly manually with an extra bundle to
move the three stores back together:
.global f1# .global f1#
.type f1#, @function .type f1#, @function
.proc f1# .proc f1#
f1: f1:
.prologue .prologue
.body .body
.mmi .mmi
mov r15 = r12 mov r15 = r12
nop 0 nop 0
mov r14 = r12 mov r14 = r12
;; ;;
.mmi .mmi
st8 [r15] = r32, 8 st8 [r15] = r32, 8
;; ;;
st8 [r15] = r33, -4 st8 [r15] = r33, -4
nop 0 nop 0
> ;;
> .mii
> st4 [r15] = r34
> nop 0
> nop 0
.mii .mii
ld8 r8 = [r14], 8 ld8 r8 = [r14], 8
nop 0 nop 0
;; ;;
nop 0 nop 0
.mmb .mmb
ld8 r9 = [r14] ld8 r9 = [r14]
st4 [r15] = r34 | nop 0
br.ret.sptk.many b0 br.ret.sptk.many b0
.endp f1# .endp f1#
I am not an ia64 expert, but I see no reason why moving the store is a bad
idea. Will have to look at the RTL, and if that doesn't help I'll leave this to
a target specialist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
