[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC

["steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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