> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Thursday, January 05, 2012 5:32 PM
> To: Jiangning Liu
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: Re: A case exposing code sink issue
>
> On Thu, Jan 5, 2012 at 9:34 AM
On Thu, Jan 5, 2012 at 9:34 AM, Jiangning Liu wrote:
>> >> > In final value replacement, expression "&a + D." can be
>> figured
>> >> out,
>> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
>> should
>> >> > lower
>> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It se
> >> > In final value replacement, expression "&a + D." can be
> figured
> >> out,
> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
> should
> >> > lower
> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It seems GCC
> intends
> >> to
> >> > keep
> >> > &a[i_xxx] until
On Thu, Dec 29, 2011 at 9:50 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jiangning Liu
>> Sent: Wednesday, December 28, 2011 5:38 PM
>> To: Jiangning Liu; 'Richard Guenther'
>> Cc: Michael Matz; gcc@gcc.gnu.org
&
> -Original Message-
> From: Jiangning Liu
> Sent: Wednesday, December 28, 2011 5:38 PM
> To: Jiangning Liu; 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
>
>
> > -Original M
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, December 27, 2011 5:10 PM
> To: 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink
>
> The job to do this is final value replacement, not sinking (we do not
> sink non-invariant expressions - you'd have to translate them through
> the loop-closed SSA exit PHI node, certainly doable, patches
> welcome ;)).
>
Richard,
In final value replacement, expression "&a + D." can be
On Thu, Dec 22, 2011 at 9:25 AM, Jiangning Liu wrote:
>> Yes, the number of iterations of the i loop simply is too difficult fo
>> our loop iteration calculator to comprehend:
>>
>> for (i=k; i<500; i+=k)
>>
>> iterates for roundup((500-k)/k) time. In particular if the step is
>> non-constant o
> Yes, the number of iterations of the i loop simply is too difficult for
> our loop iteration calculator to comprehend:
>
> for (i=k; i<500; i+=k)
>
> iterates for roundup((500-k)/k) time. In particular if the step is
> non-constant our nr-of-iteration calculator gives up.
>
I'm trying to g
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: Monday, November 28, 2011 9:07 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> Hi,
>
> On Mon, 28 Nov 2011, Jiangning Liu wrote
Hi,
On Mon, 28 Nov 2011, Jiangning Liu wrote:
> > > One more question...
> > >
> > > Can " i = i.6_18;" be sinked out of loop, because it doesn't have
> > memory
> > > dependence with others?
> >
> > With current trunk the stores to i, a_p, b_p and k are sunken after the
> > loop. (There are no
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: Friday, November 25, 2011 11:23 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> Hi,
>
> On Thu, 24 Nov 2011, Jiangning Liu w
Hi,
On Thu, 24 Nov 2011, Jiangning Liu wrote:
> One more question...
>
> Can " i = i.6_18;" be sinked out of loop, because it doesn't have memory
> dependence with others?
With current trunk the stores to i, a_p, b_p and k are sunken after the
loop. (There are no aliasing problems because the
ursday, November 24, 2011 2:57 PM
> To: gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> Sorry, I realize we can't do that optimization because a_p may have
> dependence upon other memory accesses like MEM[(int *)&a][D.2248_7].
>
> For example,
Sorry, I realize we can't do that optimization because a_p may have
dependence upon other memory accesses like MEM[(int *)&a][D.2248_7].
For example, if it happens a_p equals &a_p, that optimization would be
wrong.
But can alias analysis solve the problem if we can guarantee (i+(1< -Original
> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Thursday, November 24, 2011 12:15 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A case exposing code sink issue
>
> On Wed, Nov 23, 2011 at 8:05 PM, Jiangning Liu
>
On Wed, Nov 23, 2011 at 8:05 PM, Jiangning Liu wrote:
> If this is the root cause, which optimization pass in GCC take the role to
> sink them out of loop? How should we get it fixed?
lim1 handles the case just fine for me. lim1 is the first loop pass.
After lim1 I get:
:
# i.1_34 = PHI
D
17 matches
Mail list logo
