Bug 14193 - Restrict pointers don't help
Summary: Restrict pointers don't help
Status: RESOLVED DUPLICATE of bug 14192
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-18 14:07 UTC by Jan Hoogerbrugge
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: linux
Target: trimedia
Build: linux
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hoogerbrugge 2004-02-18 14:07:33 UTC
I have two problems. It could be that they are related.

First. In the following code there is no dependence between the two stores 
which is what I would expect:

void restricttest2(int *restrict p, int *restrict q)
{
        *p = 0;
        *q = 0;
}

However, if only one of the two pointers is restrict then gcc generates a 
dependence. 

void restricttest1(int *restrict p, int *q)
{
        *p = 0;
        *q = 0;
}

According to my interpretation of the restrict spec this is not necessary. 
Also, two other (non-gcc) compilers that I have as a reference don't generate 
this dependence.

The second case is the following loop:

void copy(int *restrict pb, int *restrict qb)
{
        int i;

        for(i = 0; i < 100; i++)
        {
                qb[i] = pb[i]; i++;
                qb[i] = pb[i]; i++;
                qb[i] = pb[i]; i++;
                qb[i] = pb[i];
        }
}

When compiled with -fno-unroll-loops I see lots of dependences between the 
loads and stores. 

_copy:
        .function
        /***************************/
        ident r6 -> r35
        ident r5 -> r34
        ident r0 -> r33
        iaddi(99) r0 -> r36
L5:     asli(2) r33 -> r51
        iaddi(1) r33 -> r52
        asli(2) r52 -> r46
        iaddi(2) r33 -> r47
        iadd r51 r34 -> r50
        asli(2) r47 -> r41
        iaddi(3) r33 -> r42
        iadd r51 r35 -> r48
        ld32 r50 -> r49         [ID=1125][REGION=2]
        iadd r46 r34 -> r45
        st32 r48 r49            [ID=1031][REGION=2]
        asli(2) r42 -> r37
        iadd r46 r35 -> r43
        ld32 r45 -> r44         [ID=1126][REGION=2]
        iadd r41 r34 -> r40
        st32 r43 r44            [ID=1040][REGION=2]
        iadd r41 r35 -> r38
        ld32 r40 -> r39         [ID=1127][REGION=2]
        iadd r37 r34 -> r9
        st32 r38 r39            [ID=1049][REGION=2]
        iaddi(4) r33 -> r33
        iadd r37 r35 -> r8
        ld32 r9 -> r7           [ID=1128][REGION=2]
        st32 r8 r7              [ID=1058][REGION=2]
        igtr r33 r36 -> r6
        if !r6 ijmpi(L5)                [PROB=96]
        /***************************/
        ijmpf r0 r2     /* return */
        .depend 1128 -> 1058
        .depend 1049 -> 1058
        .depend 1127 -> 1049
        .depend 1040 -> 1049 1058
        .depend 1126 -> 1040
        .depend 1031 -> 1040 1049 1058
        .depend 1125 -> 1031
        .endfunction

(The .depend line indicate dependences between instructions (IDs))

However, in this loop there are no dependences at all:

void zero(int *restrict qb)
{
        int i;

        for(i = 0; i < 100; i++)
        {
                qb[i] = 0; i++;
                qb[i] = 0; i++;
                qb[i] = 0; i++;
                qb[i] = 0;
        }
}

I use "gcc version 3.5.0 20040119 (experimental)"

I observe the dependences in the INSN_DEPEND(insn) list in sched_finish().
Comment 1 Andrew Pinski 2004-02-18 14:10:57 UTC
This is a dup of bug 14192.

*** This bug has been marked as a duplicate of 14192 ***