Originally posted here: http://gcc.gnu.org/ml/gcc-help/2010-04/msg00233.html

Consider the following code:

sal...@salmin:~$ cat restrict1.c
void f(int *a, const int *restrict b) {
        *a++ = *b + 1;
        *a++ = *b + 1;
}

"const *restrict" guarantee that *b will not be modified inside f and we can
eliminate a load in the second statement. However:

sal...@salmin:~$ ./systemroot/bin/gcc-trunk-158628 -S -O4 -std=gnu99
restrict1.c
sal...@salmin:~$ grep -v '[.:]' restrict1.s
        movl    (%rsi), %eax
        addl    $1, %eax
        movl    %eax, (%rdi)
        movl    (%rsi), %eax
        addl    $1, %eax
        movl    %eax, 4(%rdi)
        ret

But if we add a restrict keyword to the "a" definition it helps surprisingly:

sal...@salmin:~$ cat restrict2.c
void f(int *restrict a, const int *restrict b) {
        *a++ = *b + 1;
        *a++ = *b + 1;
}
sal...@salmin:~$ ./systemroot/bin/gcc-trunk-158628 -S -O4 -std=gnu99
restrict2.c
sal...@salmin:~$ grep -v '[.:]' restrict2.s
        movl    (%rsi), %eax
        addl    $1, %eax
        movl    %eax, (%rdi)
        movl    %eax, 4(%rdi)
        ret

Not sure if it's a duplicate bug, other restrict-related bugs I've checked
seemed different to me.


-- 
           Summary: yet another missed restrict optimization
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: alexey dot salmin at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43907

Reply via email to