Richard,
I applied the patch. The simple example in my previous mail is 
compiled as expected. However, for a bit more complex example,
restrict qualifier still doesn't work as expected. This happens
even on trunk compiler so it is not due to some missing patches on 4.5.

void foo (int * restrict a, int * restrict b, int * restrict c)
{
   int i;
   for(i = 0; i < 100; i+=4)
     {
       a[i] = b[i] * c[i];
       a[i+1] = b[i+1] * c[i+1];
       a[i+2] = b[i+2] * c[i+2];
       a[i+3] = b[i+3] * c[i+3];
     }
}

~/work/install-x86/bin/gcc tst3.c -O2 -S -std=c99 -da -fschedule-insns 
-frename-register

.L2:
        movl    (%rdx,%rax), %r10d
        imull   (%rsi,%rax), %r10d
        movl    %r10d, (%rdi,%rax)
        movl    4(%rdx,%rax), %r9d
        imull   4(%rsi,%rax), %r9d
        movl    %r9d, 4(%rdi,%rax)
        movl    8(%rdx,%rax), %r8d
        imull   8(%rsi,%rax), %r8d
        movl    %r8d, 8(%rdi,%rax)
        movl    12(%rdx,%rax), %ecx
        imull   12(%rsi,%rax), %ecx
        movl    %ecx, 12(%rdi,%rax)
        addq    $16, %rax
        cmpq    $400, %rax
        jne     .L2
        rep

This used to compile efficiently on our 4.4 port. Any comments?

Thanks,
Bingfeng    

> -----Original Message-----
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 03 August 2010 10:33
> To: Bingfeng Mei
> Cc: Alexander Monakov; gcc@gcc.gnu.org
> Subject: Re: Restrict qualifier still not working?
> 
> On Tue, Aug 3, 2010 at 10:50 AM, Bingfeng Mei <b...@broadcom.com> wrote:
> >> -----Original Message-----
> >> From: Alexander Monakov [mailto:amona...@ispras.ru]
> >> Sent: 02 August 2010 17:48
> >> To: Bingfeng Mei
> >> Cc: gcc@gcc.gnu.org; Richard Guenther
> >> Subject: Re: Restrict qualifier still not working?
> >>
> >>
> >>
> >> On Mon, 2 Aug 2010, Bingfeng Mei wrote:
> >>
> >> > Hi,
> >> > I ran a small test to see how the trunk/4.5 works
> >> > with the rewritten restrict qualified pointer code. But it doesn't
> >> > seem to work on both x86-64 and our port.
> >> >
> >> > tst.c:
> >> > void foo (int * restrict a, int * restrict b,
> >> >           int * restrict c, int * restrict d)
> >> > {
> >> >   *c = *a + 1;
> >> >   *d = *b + 1;
> >> > }
> >> [snip]
> >> > foo:
> >> > .LFB0:
> >> >     .cfi_startproc
> >> >     movl    (%rdi), %eax
> >> >     addl    $1, %eax
> >> >     movl    %eax, (%rdx)
> >> >     movl    (%rsi), %eax
> >> >     addl    $1, %eax
> >> >     movl    %eax, (%rcx)
> >> >     ret
> >> >
> >> > In the finally generated code, the second load should have
> >> > been moved before the first store if restrict qualifiers
> >> > are handled correctly.
> >> >
> >> > Am I missing something here? Thanks.
> >>
> >> The second load is moved for me with -fschedule-insns, -frename-
> >> registers or
> >> -fselective-scheduling2 (all of which are disabled by default on
> x86-64
> >> -O2).
> >> Without those flags, second scheduler alone cannot lift the load due
> to
> >> dependency on %eax.
> >>
> >> Hope that helps.
> >
> > Thanks, I can reproduce it with trunk compiler but not 4.5.0.
> > Do you know how alias set are represented and used now. It used to
> > be each alias set is assigned a unique number and there won't
> > be a dependence edge drawn between different alias set. It seems not
> > to be the case anymore. [2 *a_1(D)+0 S4 A32] The second field
> > must play a role in disambiguate the memory access.
> 
> Yes, restrict support is now implemented as part of points-to
> analysis and information is stored alongside SSA names (the a_1(D)).
> On the 4.5 branch we do not preserve them in all cases.
> 
> See the fixes for PR42617 which should apply to the branch
> (but also watch for some patches fixing fallout in that area).
> 
> Richard.
> 
> > BTW, why these two intermediate variables are both assigned to eax
> > without these non-default options? This example has no register
> pressure.
> > It looks like an issue with IRA.
> >
> >
> > Cheers,
> > Bingfeng
> >
> >
> >


Reply via email to