For the case below, the code generated by “gcc -O3” is very ugly.
char g_d[1024], g_s1[1024], g_s2[1024];
void test_loop(void)
{
char *d = g_d, *s1 = g_s1, *s2 = g_s2;
for( int y = 0; y < 128; y++ )
{
for( int x = 0; x < 16; x++ )
d[x] = s1[x] + s2[x];
om: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org]
Sent: Tuesday, July 19, 2011 6:18 PM
To: Jiangning Liu
Cc: gcc-patc...@gcc.gnu.org; vmaka...@redhat.com; dje@gmail.com; Richard
Henderson; Ramana Radhakrishnan
Subject: Re: [RFC] Add middle end hook for stack red zone size
2011/7/19 Jia
.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
> On Behalf Of Joern Rennecke
> Sent: Tuesday, July 26, 2011 10:33 AM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; vmaka...@redhat.com;
> dje@gmail.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana
> Radhakrishn
nal Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
> On Behalf Of Jakub Jelinek
> Sent: Monday, August 01, 2011 5:12 PM
> To: Jiangning Liu
> Cc: 'Joern Rennecke'; gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org;
> vmaka...@redhat.
Hi,
For the following simple test case, PRE optimization hoists computation
(s!=1) into the default branch of the switch statement, and finally causes
very poor code generation. This problem occurs in both X86 and ARM, and I
believe it is also a problem for other targets.
int f(char *t) {
in
ugust 01, 2011 6:31 PM
> To: Jiangning Liu
> Cc: 'Joern Rennecke'; gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org;
> vmaka...@redhat.com; dje@gmail.com; Richard Henderson; Ramana
> Radhakrishnan; 'Ramana Radhakrishnan'
> Subject: Re: [RFC] Add middle end hook for
Hi,
For the following small case,
int f(int i, int j)
{
if (i==1 && j==2)
return i;
else
return j;
}
with -O2 option, GCC has vrp2 dump like below,
==
Value ranges after VRP:
i_1: VARYING
i_2(D): VARYING
D.1249_3: [0, +INF]
j
1 2:27 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: Is VRP is too conservative to identify boolean value 0 and
> 1?
>
> On Thu, Sep 1, 2011 at 10:58 PM, Jiangning Liu
> wrote:
> > D.1249_3: [0, 1]
> > D.1250_5: [0, 1]
> > D.1251_6: [0, 1]
>
ts?
Thanks,
-Jiangning
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, August 02, 2011 5:23 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A case that PRE optimization hurts performance
>
> On Tue, A
Hi,
For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an invalid
C program, because the last iterations of all the loops cause the access of
arrays is beyond the max size of corresponding array declarations. The
condition of checking upper bound should be "<" rather than "<=".
Rig
PING...
> -Original Message-
> From: Jiangning Liu [mailto:jiangning@arm.com]
> Sent: Thursday, September 22, 2011 10:19 AM
> To: gcc@gcc.gnu.org
> Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
> Matthew Gretton-
> > * Without PRE,
> >
> > Path1:
> > movl $2, %eax
> > cmpl $1, %eax
> > je .L3
> >
> > Path2:
> > movb $3, %al
> > cmpl $1, %eax
> > je .L3
> >
> > Path3:
> > cmpl $1, %eax
> > jne .L14
> >
> > * With PRE,
> >
>
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, September 27, 2011 12:43 AM
> To: Richard Guenther
> Cc: Jiangning Liu; gcc@gcc.gnu.org
> Subject: Re: A case that PRE optimization hurts performance
>
> -BEGIN PGP SIGNED M
Hi,
For this test case,
int x;
extern void f(void);
void g(int *a)
{
a[x] = 1;
if (x == 100)
f();
a[x] = 2;
}
For trunk, the x86 assembly code is like below,
movlx, %eax
movl16(%esp), %ebx
movl$1, (%ebx,%eax,4)
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Friday, September 02, 2011 5:07 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: Is VRP is too conservative to identify boolean value 0 and
> 1?
>
> On
Hi,
For this small test case,
int a[512] ;
int b[512] ;
int *a_p ;
int *b_p ;
int i ;
int k ;
int f(void)
{
for( k = 1 ; k <= 9 ; k++)
{
for( i = k ; i < 512 ; i += k)
{
a_p = &a[i + (1<:
k = 1;
:
# k.0_9 = PHI
i = k
> -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
>
t; -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Thursday, November 24, 2011 12:05 PM
> To: gcc@gcc.gnu.org
> Subject: A case exposing code sink issue
>
> Hi,
>
> For this small test case,
One more question...
Can " i = i.6_18;" be sinked out of loop, because it doesn't have memory
dependence with others?
Thanks,
-Jiangning
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Th
> -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
> -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
> 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
>
> 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
> -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
> -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
> >> > 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
> -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
Hi,
For this small test case,
int *l, *r;
int test_func(void)
{
int i;
int direction;
static int pos;
pos = 0;
direction = 1;
for ( i = 0; i <= 400; i++ )
{
if ( direction == 0 )
pos = l[pos];
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Friday, February 17, 2012 5:53 PM
> To: gcc@gcc.gnu.org
> Subject: A problem about loop store motion
>
> Hi,
>
> For this small tes
> The MEM form is more "canonical", so the loop SM machinery to detect
> equality should be adjusted accordingly. Alternatively you can teach
> PRE insertion to strip off the MEM if possible (though
> fold_stmt_inplace should
> arelady do this if possible).
Richard,
Thank you! You are right. I n
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, February 21, 2012 5:40 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A problem about loop store motion
>
> On Tue, Feb 21, 2012 at 9:54 AM, Jiangnin
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: Tuesday, February 21, 2012 6:19 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A problem about loop store motion
>
> On Tu
Hi,
For the small case below, there are some redundant PHI expression stmt
generated, and finally cause back-end generates redundant copy instructions
due to some reasons around IRA.
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, di
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> William J. Schmidt
> Sent: Monday, February 27, 2012 11:32 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: Re: A question about redundan
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, February 28, 2012 11:19 AM
> To: 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question abou
> -Original Message-
> From: Jiangning Liu
> Sent: Tuesday, February 28, 2012 4:07 PM
> To: Jiangning Liu; 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question about redundant PHI expression stmt
>
>
>
> &g
Hi,
For this small case,
char garr[100];
void f(void)
{
unsigned short h, s;
s = 20;
for (h = 1; h < (s-1); h++)
{
garr[h] = 0;
}
}
After copyrename3, we have the following dump,
f ()
{
short unsigned int h;
int D.4066;
:
D.4066_
Hi,
Why can't we replace function force_expr_to_var_cost directly with function
computation_cost in tree-ssa-loop-ivopt.c?
Actually I think it is inaccurate for the current recursive algorithm in
force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
count some back-end factor
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 15, 2012 10:17 PM
> To: Zdenek Dvorak
> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu
> Subject: Re: A question about loop ivopt
>
> On Tue, May 15, 2012 a
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 22, 2012 6:36 PM
> To: Jiangning Liu
> Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org
> Subject: Re: A question about loop ivopt
>
> On Tue, May 22, 2012 at
40 matches
Mail list logo
