Patchwork Fix a bug in merging uninitialized refs into a single web

login
register
mail settings
Submitter Jie Zhang
Date Jan. 5, 2011, 11:04 a.m.
Message ID <4D245036.4040807@codesourcery.com>
Download mbox | patch
Permalink /patch/77586/
State New
Headers show

Comments

Jie Zhang - Jan. 5, 2011, 11:04 a.m.
Hi,

When investigating a performance regression issue of ARM GCC on 
Dhrystone, I found this bug. Dhrystone contains code like this (already 
reduced):

foo ()
{
}

i.e. returns an uninitialized value. Currently GCC will produce the 
following assembly for the above function with option "-O2 -funroll-loops":

foo:
	mov	r0, #0
	bx	lr

while previously GCC generated

foo:
	bx	lr

I tracked this down to the web pass. Before that pass:

(insn 8 7 6 2 (clobber (reg:SI 134 [ <retval> ])) t.c:1 -1
      (nil))

(insn 6 8 9 2 (set (reg/i:SI 0 r0)
         (reg:SI 134 [ <retval> ])) t.c:1 168 {*arm_movsi_insn}
      (expr_list:REG_DEAD (reg:SI 134 [ <retval> ])
         (nil)))

After that pass:

(insn 8 7 6 2 (clobber (reg:SI 134 [ <retval> ])) t.c:1 -1
      (nil))

(insn 6 8 9 2 (set (reg/i:SI 0 r0)
         (reg:SI 135 [ <retval> ])) t.c:1 168 {*arm_movsi_insn}
      (expr_list:REG_DEAD (reg:SI 134 [ <retval> ])
         (nil)))

The web pass replaces (reg 134) in insn 6 by (reg 135) because the 
definition of (reg 134) in insn 8 and the use of (reg 134) in insn 6 are 
in two different webs. It surprised me since the web pass should have 
already merged uninitialized refs into a single web. When I looked 
closer, I found there was a small bug in the merging code:

   /* In case the original register is already assigned, generate new
      one.  Since we use USED to merge uninitialized refs into a single
      web, we might found an element to be nonzero without our having
      used it.  Test for 1, because union_defs saves it for our use,
      and there won't be any use for the other values when we get to
      this point.  */
   if (used[REGNO (reg)] != 1)
     newreg = reg, used[REGNO (reg)] = 1;

The merging code uses used[] to keep the DF_REF_ID of the first 
uninitialized uses of a register. But the above code will clobber it and 
set it to 1 when it sees the definition in insn 8. Thus when come the 
reference in insn 6, (used[REGNO (reg)] != 1) will not be true and 
another code path will be chosen to produce a new register.

The patch is attached. Bootstrapped and regression tested on 
x86_64-linux-gnu. Since it fixes the patch for PR42631, I still use that 
PR for record. Is it OK?


Regards,
Jeff Law - Jan. 5, 2011, 6:09 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/05/11 04:04, Jie Zhang wrote:
> Hi,
> 
> When investigating a performance regression issue of ARM GCC on
> Dhrystone, I found this bug. Dhrystone contains code like this (already
> reduced):
> 
> foo ()
> {
> }
> 
> i.e. returns an uninitialized value. Currently GCC will produce the
> following assembly for the above function with option "-O2 -funroll-loops":
> 
> foo:
>     mov    r0, #0
>     bx    lr
> 
> while previously GCC generated
> 
> foo:
>     bx    lr
> 
> I tracked this down to the web pass. Before that pass:
> 
> (insn 8 7 6 2 (clobber (reg:SI 134 [ <retval> ])) t.c:1 -1
>      (nil))
> 
> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>         (reg:SI 134 [ <retval> ])) t.c:1 168 {*arm_movsi_insn}
>      (expr_list:REG_DEAD (reg:SI 134 [ <retval> ])
>         (nil)))
> 
> After that pass:
> 
> (insn 8 7 6 2 (clobber (reg:SI 134 [ <retval> ])) t.c:1 -1
>      (nil))
> 
> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>         (reg:SI 135 [ <retval> ])) t.c:1 168 {*arm_movsi_insn}
>      (expr_list:REG_DEAD (reg:SI 134 [ <retval> ])
>         (nil)))
> 
> The web pass replaces (reg 134) in insn 6 by (reg 135) because the
> definition of (reg 134) in insn 8 and the use of (reg 134) in insn 6 are
> in two different webs. It surprised me since the web pass should have
> already merged uninitialized refs into a single web. When I looked
> closer, I found there was a small bug in the merging code:
> 
>   /* In case the original register is already assigned, generate new
>      one.  Since we use USED to merge uninitialized refs into a single
>      web, we might found an element to be nonzero without our having
>      used it.  Test for 1, because union_defs saves it for our use,
>      and there won't be any use for the other values when we get to
>      this point.  */
>   if (used[REGNO (reg)] != 1)
>     newreg = reg, used[REGNO (reg)] = 1;
> 
> The merging code uses used[] to keep the DF_REF_ID of the first
> uninitialized uses of a register. But the above code will clobber it and
> set it to 1 when it sees the definition in insn 8. Thus when come the
> reference in insn 6, (used[REGNO (reg)] != 1) will not be true and
> another code path will be chosen to produce a new register.
> 
> The patch is attached. Bootstrapped and regression tested on
> x86_64-linux-gnu. Since it fixes the patch for PR42631, I still use that
> PR for record. Is it OK?
ISTM the web pass should probably be ignoring this clobber.  The only
purpose for the clobber is keep the dataflow code from making the return
register live across the entire function.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNJLPgAAoJEBRtltQi2kC7FjMIAJWlwPynuhRfcEt/ibitrXEc
1Rkk1Yck3gBhiSjvipJzcGFPlsaSqeDSsBrG2Ovf1l6CVnyWpfduQhtGAuShgPVY
+cLlNiqAUlDJC7HTc/DtREacDA5XkcCeRm22q2UxZ5OMgQhPyD60VUGdgGrxMnHS
tFpCAq20Xi3wdu+LD+6XiFQGBnwzUJYBsTDEMSFoJ7O2H9gUH8ffHczGKXsX6+pc
4QDf727I9qLt63GLWgltmtxDBGaYEKbd0+XD8A+z9zfBx39o6ZStw36T0YwvSQXj
ehnERyT2jbq1D3JyQiOlHcUb/8/c3JO1cnQCqVtFmhqzbeQyQZZSiPScR/DqITo=
=ncqV
-----END PGP SIGNATURE-----
Jie Zhang - Jan. 6, 2011, 2:21 a.m.
On 01/06/2011 02:09 AM, Jeff Law wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/05/11 04:04, Jie Zhang wrote:
>> Hi,
>>
>> When investigating a performance regression issue of ARM GCC on
>> Dhrystone, I found this bug. Dhrystone contains code like this (already
>> reduced):
>>
>> foo ()
>> {
>> }
>>
>> i.e. returns an uninitialized value. Currently GCC will produce the
>> following assembly for the above function with option "-O2 -funroll-loops":
>>
>> foo:
>>      mov    r0, #0
>>      bx    lr
>>
>> while previously GCC generated
>>
>> foo:
>>      bx    lr
>>
>> I tracked this down to the web pass. Before that pass:
>>
>> (insn 8 7 6 2 (clobber (reg:SI 134 [<retval>  ])) t.c:1 -1
>>       (nil))
>>
>> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>>          (reg:SI 134 [<retval>  ])) t.c:1 168 {*arm_movsi_insn}
>>       (expr_list:REG_DEAD (reg:SI 134 [<retval>  ])
>>          (nil)))
>>
>> After that pass:
>>
>> (insn 8 7 6 2 (clobber (reg:SI 134 [<retval>  ])) t.c:1 -1
>>       (nil))
>>
>> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>>          (reg:SI 135 [<retval>  ])) t.c:1 168 {*arm_movsi_insn}
>>       (expr_list:REG_DEAD (reg:SI 134 [<retval>  ])
>>          (nil)))
>>
>> The web pass replaces (reg 134) in insn 6 by (reg 135) because the
>> definition of (reg 134) in insn 8 and the use of (reg 134) in insn 6 are
>> in two different webs. It surprised me since the web pass should have
>> already merged uninitialized refs into a single web. When I looked
>> closer, I found there was a small bug in the merging code:
>>
>>    /* In case the original register is already assigned, generate new
>>       one.  Since we use USED to merge uninitialized refs into a single
>>       web, we might found an element to be nonzero without our having
>>       used it.  Test for 1, because union_defs saves it for our use,
>>       and there won't be any use for the other values when we get to
>>       this point.  */
>>    if (used[REGNO (reg)] != 1)
>>      newreg = reg, used[REGNO (reg)] = 1;
>>
>> The merging code uses used[] to keep the DF_REF_ID of the first
>> uninitialized uses of a register. But the above code will clobber it and
>> set it to 1 when it sees the definition in insn 8. Thus when come the
>> reference in insn 6, (used[REGNO (reg)] != 1) will not be true and
>> another code path will be chosen to produce a new register.
>>
>> The patch is attached. Bootstrapped and regression tested on
>> x86_64-linux-gnu. Since it fixes the patch for PR42631, I still use that
>> PR for record. Is it OK?
> ISTM the web pass should probably be ignoring this clobber.  The only
> purpose for the clobber is keep the dataflow code from making the return
> register live across the entire function.
>
Thanks for review. Yeah. I thought about ignoring the clobber at first. 
But later I found there was a bug in the code which merges uninitialized 
refs into a single web and fixing that bug should also fix the issue I 
encountered. So I just try to fix that bug which will be safer and 
easier for me.

Actually, currently GCC only merges the first two uninitialized refs but 
still assigns new registers for the remaining refs. Take the testcase 
from PR42631 as an example:

================== testcase.c ==================
void foo()
{
   unsigned k; /* doesn't crash with 'int' or when initialized */
   while (--k > 0);
}
================================================

Before r155765, which added merging uninitialized refs into a single web:

$ ./cc1 -O1 -funroll-loops  testcase.c -fdump-rtl-web -quiet ; grep "Web 
oldreg" testcase.c.171r.web
Web oldreg=62 newreg=66
Web oldreg=62 newreg=67
Web oldreg=62 newreg=68
Web oldreg=62 newreg=69
Web oldreg=62 newreg=70
Web oldreg=62 newreg=71
Web oldreg=62 newreg=72
Web oldreg=62 newreg=73
Web oldreg=62 newreg=74
$

Current GCC creates one less new regs because it combines the first two 
uses of (reg 62)

$ ./cc1 -O1 -funroll-loops  testcase.c -fdump-rtl-web -quiet ; grep "Web 
oldreg" testcase.c.171r.web
Web oldreg=62 newreg=66
Web oldreg=62 newreg=67
Web oldreg=62 newreg=68
Web oldreg=62 newreg=69
Web oldreg=62 newreg=70
Web oldreg=62 newreg=71
Web oldreg=62 newreg=72
Web oldreg=62 newreg=73
$

With my patch, all refs to (reg 62) will be combined:

$ ./cc1 -O1 -funroll-loops  testcase.c -fdump-rtl-web -quiet ; grep "Web 
oldreg" testcase.c.171r.web
$


Regards,
Jie Zhang - Jan. 10, 2011, 2:47 a.m.
Hi Alex,

Since you are the author of the code my patch changes, could you please 
take a look at my patch and confirm that it does the right thing. Thanks!

Jie

On 01/06/2011 10:21 AM, Jie Zhang wrote:
> On 01/06/2011 02:09 AM, Jeff Law wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/05/11 04:04, Jie Zhang wrote:
>>> Hi,
>>>
>>> When investigating a performance regression issue of ARM GCC on
>>> Dhrystone, I found this bug. Dhrystone contains code like this (already
>>> reduced):
>>>
>>> foo ()
>>> {
>>> }
>>>
>>> i.e. returns an uninitialized value. Currently GCC will produce the
>>> following assembly for the above function with option "-O2
>>> -funroll-loops":
>>>
>>> foo:
>>> mov r0, #0
>>> bx lr
>>>
>>> while previously GCC generated
>>>
>>> foo:
>>> bx lr
>>>
>>> I tracked this down to the web pass. Before that pass:
>>>
>>> (insn 8 7 6 2 (clobber (reg:SI 134 [<retval> ])) t.c:1 -1
>>> (nil))
>>>
>>> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>>> (reg:SI 134 [<retval> ])) t.c:1 168 {*arm_movsi_insn}
>>> (expr_list:REG_DEAD (reg:SI 134 [<retval> ])
>>> (nil)))
>>>
>>> After that pass:
>>>
>>> (insn 8 7 6 2 (clobber (reg:SI 134 [<retval> ])) t.c:1 -1
>>> (nil))
>>>
>>> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>>> (reg:SI 135 [<retval> ])) t.c:1 168 {*arm_movsi_insn}
>>> (expr_list:REG_DEAD (reg:SI 134 [<retval> ])
>>> (nil)))
>>>
>>> The web pass replaces (reg 134) in insn 6 by (reg 135) because the
>>> definition of (reg 134) in insn 8 and the use of (reg 134) in insn 6 are
>>> in two different webs. It surprised me since the web pass should have
>>> already merged uninitialized refs into a single web. When I looked
>>> closer, I found there was a small bug in the merging code:
>>>
>>> /* In case the original register is already assigned, generate new
>>> one. Since we use USED to merge uninitialized refs into a single
>>> web, we might found an element to be nonzero without our having
>>> used it. Test for 1, because union_defs saves it for our use,
>>> and there won't be any use for the other values when we get to
>>> this point. */
>>> if (used[REGNO (reg)] != 1)
>>> newreg = reg, used[REGNO (reg)] = 1;
>>>
>>> The merging code uses used[] to keep the DF_REF_ID of the first
>>> uninitialized uses of a register. But the above code will clobber it and
>>> set it to 1 when it sees the definition in insn 8. Thus when come the
>>> reference in insn 6, (used[REGNO (reg)] != 1) will not be true and
>>> another code path will be chosen to produce a new register.
>>>
>>> The patch is attached. Bootstrapped and regression tested on
>>> x86_64-linux-gnu. Since it fixes the patch for PR42631, I still use that
>>> PR for record. Is it OK?
>> ISTM the web pass should probably be ignoring this clobber. The only
>> purpose for the clobber is keep the dataflow code from making the return
>> register live across the entire function.
>>
> Thanks for review. Yeah. I thought about ignoring the clobber at first.
> But later I found there was a bug in the code which merges uninitialized
> refs into a single web and fixing that bug should also fix the issue I
> encountered. So I just try to fix that bug which will be safer and
> easier for me.
>
> Actually, currently GCC only merges the first two uninitialized refs but
> still assigns new registers for the remaining refs. Take the testcase
> from PR42631 as an example:
>
> ================== testcase.c ==================
> void foo()
> {
> unsigned k; /* doesn't crash with 'int' or when initialized */
> while (--k > 0);
> }
> ================================================
>
> Before r155765, which added merging uninitialized refs into a single web:
>
> $ ./cc1 -O1 -funroll-loops testcase.c -fdump-rtl-web -quiet ; grep "Web
> oldreg" testcase.c.171r.web
> Web oldreg=62 newreg=66
> Web oldreg=62 newreg=67
> Web oldreg=62 newreg=68
> Web oldreg=62 newreg=69
> Web oldreg=62 newreg=70
> Web oldreg=62 newreg=71
> Web oldreg=62 newreg=72
> Web oldreg=62 newreg=73
> Web oldreg=62 newreg=74
> $
>
> Current GCC creates one less new regs because it combines the first two
> uses of (reg 62)
>
> $ ./cc1 -O1 -funroll-loops testcase.c -fdump-rtl-web -quiet ; grep "Web
> oldreg" testcase.c.171r.web
> Web oldreg=62 newreg=66
> Web oldreg=62 newreg=67
> Web oldreg=62 newreg=68
> Web oldreg=62 newreg=69
> Web oldreg=62 newreg=70
> Web oldreg=62 newreg=71
> Web oldreg=62 newreg=72
> Web oldreg=62 newreg=73
> $
>
> With my patch, all refs to (reg 62) will be combined:
>
> $ ./cc1 -O1 -funroll-loops testcase.c -fdump-rtl-web -quiet ; grep "Web
> oldreg" testcase.c.171r.web
> $
>
>
Jie Zhang - Jan. 17, 2011, 2:08 a.m.
PING.

On 01/10/2011 10:47 AM, Jie Zhang wrote:
> Hi Alex,
>
> Since you are the author of the code my patch changes, could you please
> take a look at my patch and confirm that it does the right thing. Thanks!
>
> Jie
>
> On 01/06/2011 10:21 AM, Jie Zhang wrote:
>> On 01/06/2011 02:09 AM, Jeff Law wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 01/05/11 04:04, Jie Zhang wrote:
>>>> Hi,
>>>>
>>>> When investigating a performance regression issue of ARM GCC on
>>>> Dhrystone, I found this bug. Dhrystone contains code like this (already
>>>> reduced):
>>>>
>>>> foo ()
>>>> {
>>>> }
>>>>
>>>> i.e. returns an uninitialized value. Currently GCC will produce the
>>>> following assembly for the above function with option "-O2
>>>> -funroll-loops":
>>>>
>>>> foo:
>>>> mov r0, #0
>>>> bx lr
>>>>
>>>> while previously GCC generated
>>>>
>>>> foo:
>>>> bx lr
>>>>
>>>> I tracked this down to the web pass. Before that pass:
>>>>
>>>> (insn 8 7 6 2 (clobber (reg:SI 134 [<retval> ])) t.c:1 -1
>>>> (nil))
>>>>
>>>> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>>>> (reg:SI 134 [<retval> ])) t.c:1 168 {*arm_movsi_insn}
>>>> (expr_list:REG_DEAD (reg:SI 134 [<retval> ])
>>>> (nil)))
>>>>
>>>> After that pass:
>>>>
>>>> (insn 8 7 6 2 (clobber (reg:SI 134 [<retval> ])) t.c:1 -1
>>>> (nil))
>>>>
>>>> (insn 6 8 9 2 (set (reg/i:SI 0 r0)
>>>> (reg:SI 135 [<retval> ])) t.c:1 168 {*arm_movsi_insn}
>>>> (expr_list:REG_DEAD (reg:SI 134 [<retval> ])
>>>> (nil)))
>>>>
>>>> The web pass replaces (reg 134) in insn 6 by (reg 135) because the
>>>> definition of (reg 134) in insn 8 and the use of (reg 134) in insn 6
>>>> are
>>>> in two different webs. It surprised me since the web pass should have
>>>> already merged uninitialized refs into a single web. When I looked
>>>> closer, I found there was a small bug in the merging code:
>>>>
>>>> /* In case the original register is already assigned, generate new
>>>> one. Since we use USED to merge uninitialized refs into a single
>>>> web, we might found an element to be nonzero without our having
>>>> used it. Test for 1, because union_defs saves it for our use,
>>>> and there won't be any use for the other values when we get to
>>>> this point. */
>>>> if (used[REGNO (reg)] != 1)
>>>> newreg = reg, used[REGNO (reg)] = 1;
>>>>
>>>> The merging code uses used[] to keep the DF_REF_ID of the first
>>>> uninitialized uses of a register. But the above code will clobber it
>>>> and
>>>> set it to 1 when it sees the definition in insn 8. Thus when come the
>>>> reference in insn 6, (used[REGNO (reg)] != 1) will not be true and
>>>> another code path will be chosen to produce a new register.
>>>>
>>>> The patch is attached. Bootstrapped and regression tested on
>>>> x86_64-linux-gnu. Since it fixes the patch for PR42631, I still use
>>>> that
>>>> PR for record. Is it OK?
>>> ISTM the web pass should probably be ignoring this clobber. The only
>>> purpose for the clobber is keep the dataflow code from making the return
>>> register live across the entire function.
>>>
>> Thanks for review. Yeah. I thought about ignoring the clobber at first.
>> But later I found there was a bug in the code which merges uninitialized
>> refs into a single web and fixing that bug should also fix the issue I
>> encountered. So I just try to fix that bug which will be safer and
>> easier for me.
>>
>> Actually, currently GCC only merges the first two uninitialized refs but
>> still assigns new registers for the remaining refs. Take the testcase
>> from PR42631 as an example:
>>
>> ================== testcase.c ==================
>> void foo()
>> {
>> unsigned k; /* doesn't crash with 'int' or when initialized */
>> while (--k > 0);
>> }
>> ================================================
>>
>> Before r155765, which added merging uninitialized refs into a single web:
>>
>> $ ./cc1 -O1 -funroll-loops testcase.c -fdump-rtl-web -quiet ; grep "Web
>> oldreg" testcase.c.171r.web
>> Web oldreg=62 newreg=66
>> Web oldreg=62 newreg=67
>> Web oldreg=62 newreg=68
>> Web oldreg=62 newreg=69
>> Web oldreg=62 newreg=70
>> Web oldreg=62 newreg=71
>> Web oldreg=62 newreg=72
>> Web oldreg=62 newreg=73
>> Web oldreg=62 newreg=74
>> $
>>
>> Current GCC creates one less new regs because it combines the first two
>> uses of (reg 62)
>>
>> $ ./cc1 -O1 -funroll-loops testcase.c -fdump-rtl-web -quiet ; grep "Web
>> oldreg" testcase.c.171r.web
>> Web oldreg=62 newreg=66
>> Web oldreg=62 newreg=67
>> Web oldreg=62 newreg=68
>> Web oldreg=62 newreg=69
>> Web oldreg=62 newreg=70
>> Web oldreg=62 newreg=71
>> Web oldreg=62 newreg=72
>> Web oldreg=62 newreg=73
>> $
>>
>> With my patch, all refs to (reg 62) will be combined:
>>
>> $ ./cc1 -O1 -funroll-loops testcase.c -fdump-rtl-web -quiet ; grep "Web
>> oldreg" testcase.c.171r.web
>> $
>>
>>
Alexandre Oliva - Jan. 17, 2011, 3:05 p.m.
On Jan 10, 2011, Jie Zhang <jie@codesourcery.com> wrote:

> Since you are the author of the code my patch changes, could you
> please take a look at my patch and confirm that it does the right
> thing.

Yeah, now that I looked again at my patch from back then, yours makes
perfect sense to me.  Thanks!
Jie Zhang - Jan. 17, 2011, 3:27 p.m.
Alex,

On 01/17/2011 11:05 PM, Alexandre Oliva wrote:
> On Jan 10, 2011, Jie Zhang<jie@codesourcery.com>  wrote:
>
>> Since you are the author of the code my patch changes, could you
>> please take a look at my patch and confirm that it does the right
>> thing.
>
> Yeah, now that I looked again at my patch from back then, yours makes
> perfect sense to me.  Thanks!
>
Thanks! But I think I still need approval, right?

Jeff, could you approve my patch?

Regards,
Jie Zhang - Jan. 25, 2011, 3:43 a.m.
Hi Richard,

You approved Alexandre's original patch. Could you please also approve 
my patch which fixes a bug in that patch? Thanks!

On 01/17/2011 11:05 PM, Alexandre Oliva wrote:
> On Jan 10, 2011, Jie Zhang<jie@codesourcery.com>  wrote:
>
>> Since you are the author of the code my patch changes, could you
>> please take a look at my patch and confirm that it does the right
>> thing.
>
> Yeah, now that I looked again at my patch from back then, yours makes
> perfect sense to me.  Thanks!
>
Richard Guenther - Jan. 25, 2011, 12:08 p.m.
On Tue, Jan 25, 2011 at 4:43 AM, Jie Zhang <jie@codesourcery.com> wrote:
> Hi Richard,
>
> You approved Alexandre's original patch. Could you please also approve my
> patch which fixes a bug in that patch? Thanks!

Did I? ...

Well, I'm not familiar with the code, so I'll defer to somebody else.

Richard.

> On 01/17/2011 11:05 PM, Alexandre Oliva wrote:
>>
>> On Jan 10, 2011, Jie Zhang<jie@codesourcery.com>  wrote:
>>
>>> Since you are the author of the code my patch changes, could you
>>> please take a look at my patch and confirm that it does the right
>>> thing.
>>
>> Yeah, now that I looked again at my patch from back then, yours makes
>> perfect sense to me.  Thanks!
>>
>
> --
> Jie Zhang
>
>
Jie Zhang - Jan. 25, 2011, 12:15 p.m.
On 01/25/2011 08:08 PM, Richard Guenther wrote:
> On Tue, Jan 25, 2011 at 4:43 AM, Jie Zhang<jie@codesourcery.com>  wrote:
>> Hi Richard,
>>
>> You approved Alexandre's original patch. Could you please also approve my
>> patch which fixes a bug in that patch? Thanks!
>
> Did I? ...
>
Yes, you did. See

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00372.html

> Well, I'm not familiar with the code, so I'll defer to somebody else.
>
Alexandre has already confirmed that my fix is OK. But it seems he could 
not approve it since his original patch was approved by you. So I 
thought you must be familiar with the code and could also approve mine.

>> On 01/17/2011 11:05 PM, Alexandre Oliva wrote:
>>>
>>> On Jan 10, 2011, Jie Zhang<jie@codesourcery.com>    wrote:
>>>
>>>> Since you are the author of the code my patch changes, could you
>>>> please take a look at my patch and confirm that it does the right
>>>> thing.
>>>
>>> Yeah, now that I looked again at my patch from back then, yours makes
>>> perfect sense to me.  Thanks!
>>>

Regards,
Richard Guenther - Jan. 25, 2011, 12:18 p.m.
On Tue, Jan 25, 2011 at 1:15 PM, Jie Zhang <jie@codesourcery.com> wrote:
> On 01/25/2011 08:08 PM, Richard Guenther wrote:
>>
>> On Tue, Jan 25, 2011 at 4:43 AM, Jie Zhang<jie@codesourcery.com>  wrote:
>>>
>>> Hi Richard,
>>>
>>> You approved Alexandre's original patch. Could you please also approve my
>>> patch which fixes a bug in that patch? Thanks!
>>
>> Did I? ...
>>
> Yes, you did. See
>
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00372.html
>
>> Well, I'm not familiar with the code, so I'll defer to somebody else.
>>
> Alexandre has already confirmed that my fix is OK. But it seems he could not
> approve it since his original patch was approved by you. So I thought you
> must be familiar with the code and could also approve mine.

Heh, I relied on Steven here.  As Jeff already had a look maybe he
can approve your patch.

Richard.

>>> On 01/17/2011 11:05 PM, Alexandre Oliva wrote:
>>>>
>>>> On Jan 10, 2011, Jie Zhang<jie@codesourcery.com>    wrote:
>>>>
>>>>> Since you are the author of the code my patch changes, could you
>>>>> please take a look at my patch and confirm that it does the right
>>>>> thing.
>>>>
>>>> Yeah, now that I looked again at my patch from back then, yours makes
>>>> perfect sense to me.  Thanks!
>>>>
>
> Regards,
> --
> Jie Zhang
>
>
Jie Zhang - Jan. 25, 2011, 12:28 p.m.
On 01/25/2011 08:18 PM, Richard Guenther wrote:
> On Tue, Jan 25, 2011 at 1:15 PM, Jie Zhang<jie@codesourcery.com>  wrote:
>> On 01/25/2011 08:08 PM, Richard Guenther wrote:
>>>
>>> On Tue, Jan 25, 2011 at 4:43 AM, Jie Zhang<jie@codesourcery.com>    wrote:
>>>>
>>>> Hi Richard,
>>>>
>>>> You approved Alexandre's original patch. Could you please also approve my
>>>> patch which fixes a bug in that patch? Thanks!
>>>
>>> Did I? ...
>>>
>> Yes, you did. See
>>
>> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00372.html
>>
>>> Well, I'm not familiar with the code, so I'll defer to somebody else.
>>>
>> Alexandre has already confirmed that my fix is OK. But it seems he could not
>> approve it since his original patch was approved by you. So I thought you
>> must be familiar with the code and could also approve mine.
>
> Heh, I relied on Steven here.  As Jeff already had a look maybe he
> can approve your patch.
>
I asked Jeff, but there was no reply. So I thought the quickest way to 
get my patch approved might be asking you.

>>>> On 01/17/2011 11:05 PM, Alexandre Oliva wrote:
>>>>>
>>>>> On Jan 10, 2011, Jie Zhang<jie@codesourcery.com>      wrote:
>>>>>
>>>>>> Since you are the author of the code my patch changes, could you
>>>>>> please take a look at my patch and confirm that it does the right
>>>>>> thing.
>>>>>
>>>>> Yeah, now that I looked again at my patch from back then, yours makes
>>>>> perfect sense to me.  Thanks!
>>>>>


Regards,
Jie
Jeff Law - Jan. 28, 2011, 4:15 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/05/11 19:21, Jie Zhang wrote:
> On 01/06/2011 02:09 AM, Jeff Law wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/05/11 04:04, Jie Zhang wrote:
>>> Hi,
>>>
>>> When investigating a performance regression issue of ARM GCC on
>>> Dhrystone, I found this bug. Dhrystone contains code like this (already
>>> reduced):
>>>
>>> foo ()
>>> {
>>> }
>>>
>>> i.e. returns an uninitialized value. Currently GCC will produce the
>>> following assembly for the above function with option "-O2
>>> -funroll-loops":
>>>
>>
[ ... [
Not forgotten.  It's a bit of a hectic week here...  Things will be more
normal time-wise next week.

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNQkL9AAoJEBRtltQi2kC77c0H/AxlNNJB/F1vVXQ/XnxwuwID
/ZJRwr2Xm68p+Cu4/7JjqCH9uSA+Yub5Qbs6MD1itofvhX0AEoBd3hZEgYQpKzwl
djk+Lu2VzaP69yb/inm924vWPSFMfJx4Z+ohR7kDMg0SWAtlMvG64PYqPB7DsnI4
lXyqdtEsAgfW2F3ePloDikStySmTpotXwrdR1wNqM++MSHvsNJNYue6Ko5SCWXmO
PlaEXRdz8GZyn8HnSSNoQO3BbDXxukimyrGseNQdhPHBa7Os2cF022hC5KN0vxJu
w5326qXl+JbHAraAeIYpGPz81BHtVZBdz/RL2h1vt/uWca6oe9K/5DGxaXx8j2E=
=1kKN
-----END PGP SIGNATURE-----
Jie Zhang - Jan. 28, 2011, 4:29 a.m.
On 01/28/2011 12:15 PM, Jeff Law wrote:
> Not forgotten.  It's a bit of a hectic week here...  Things will be more
> normal time-wise next week.
>
I will wait.


Regards,
Jeff Law - Feb. 3, 2011, 4:44 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry for the long delay -- I probably should have asked someone else to
own this since my initial comments were solely on the CLOBBER issue and
I didn't have any familiarity with the web pass.

Regardless,


On 01/05/11 19:21, Jie Zhang wrote:

>>
> Thanks for review. Yeah. I thought about ignoring the clobber at first.
> But later I found there was a bug in the code which merges uninitialized
> refs into a single web and fixing that bug should also fix the issue I
> encountered. So I just try to fix that bug which will be safer and
> easier for me.
So just so I'm certain I understand the problem.  In the original
testcase a naked CLOBBER was the "set" that triggered the problem, but
this problem can occur for assignments to any uninitialized pseudo, such
as in examples you provided below.

When we see a set to an uninitialized pseudo, we're losing the saved
DF_REF_UID which allows us to combine all the uninitialized uses into a
single web.  Right?

Assuming that those statements are correct, the patch is OK.  I would
suggest including both the testcase derived from dhrystone as well as
the one in this message in the testsuite.

As a 4.7 cleanup, you might consider ignoring naked clobbers in the
FOR_BB_INSNS loops within web_main.


> 
> Actually, currently GCC only merges the first two uninitialized refs but
> still assigns new registers for the remaining refs. Take the testcase
> from PR42631 as an example:
> 
> ================== testcase.c ==================
> void foo()
> {
>   unsigned k; /* doesn't crash with 'int' or when initialized */
>   while (--k > 0);
> }
> ================================================
> 
> Before r155765, which added merging uninitialized refs into a single web:
> 
> $ ./cc1 -O1 -funroll-loops  testcase.c -fdump-rtl-web -quiet ; grep "Web
> oldreg" testcase.c.171r.web
> Web oldreg=62 newreg=66
> Web oldreg=62 newreg=67
> Web oldreg=62 newreg=68
> Web oldreg=62 newreg=69
> Web oldreg=62 newreg=70
> Web oldreg=62 newreg=71
> Web oldreg=62 newreg=72
> Web oldreg=62 newreg=73
> Web oldreg=62 newreg=74
> $
> 
> Current GCC creates one less new regs because it combines the first two
> uses of (reg 62)
> 
> $ ./cc1 -O1 -funroll-loops  testcase.c -fdump-rtl-web -quiet ; grep "Web
> oldreg" testcase.c.171r.web
> Web oldreg=62 newreg=66
> Web oldreg=62 newreg=67
> Web oldreg=62 newreg=68
> Web oldreg=62 newreg=69
> Web oldreg=62 newreg=70
> Web oldreg=62 newreg=71
> Web oldreg=62 newreg=72
> Web oldreg=62 newreg=73
> $
> 
> With my patch, all refs to (reg 62) will be combined:
> 
> $ ./cc1 -O1 -funroll-loops  testcase.c -fdump-rtl-web -quiet ; grep "Web
> oldreg" testcase.c.171r.web
Please include the testcase above as well as the one from dhrystone in
the testsuite.

Thanks,
Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNStuCAAoJEBRtltQi2kC7UGEIAJtLzraBzS3tofASAnXDV+JA
Hcfh9HFhbP+Nf86r0ZX9p1ka5kZ+tFCtfvaNmVSn0WPoVILq5IzXojpN+0L1pd7d
OvxKaHqDsoQ42FrRcsaa6KqvUGPWjkiYFo/48IiTWgkRLsR9U4K9Tr0wdicnfYqK
cRi7pBPLeZR9mROpwXHDjyO5naPNfLOYRiOkJ90Io7MZtPqL6jRi3/5Mrrif4UV/
HR7np3ejGZx1kP6atb21iZZmRyFgThbpT8CA9wxF+FF6+rvUDS/ZYxwN7ym0TYYr
LN5QFOxbkFQ9T3IyZAqEfbIEmmrXVnZbn6rXNy3Gfhy3zmaLG3MS5gPZlMGZsAI=
=3mqj
-----END PGP SIGNATURE-----

Patch


	PR debug/42631
	* web.c (entry_register): Don't clobber the number of the
	first uninitialized reference in used[].

	testsuite/
	PR debug/42631
	* gcc.dg/pr42631-2.c: New test.

Index: testsuite/gcc.dg/pr42631-2.c
===================================================================
--- testsuite/gcc.dg/pr42631-2.c	(revision 0)
+++ testsuite/gcc.dg/pr42631-2.c	(revision 0)
@@ -0,0 +1,9 @@ 
+/* { dg-do compile } */
+/* { dg-options "-O2 -funroll-loops -fdump-rtl-web" } */
+
+foo()
+{
+}
+
+/* { dg-final { scan-rtl-dump-not "Web oldreg" "web" } } */
+/* { dg-final { cleanup-rtl-dump "web" } } */
Index: web.c
===================================================================
--- web.c	(revision 168504)
+++ web.c	(working copy)
@@ -260,7 +260,11 @@  entry_register (struct web_entry *entry,
      and there won't be any use for the other values when we get to
      this point.  */
   if (used[REGNO (reg)] != 1)
-    newreg = reg, used[REGNO (reg)] = 1;
+    {
+      newreg = reg;
+      if (!used[REGNO (reg)])
+	used[REGNO (reg)] = 1;
+    }
   else
     {
       newreg = gen_reg_rtx (GET_MODE (reg));