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