http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> 2012-04-11 14:07:27 UTC --- On Wed, 11 Apr 2012, aldyh at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 > > --- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-04-11 > 13:37:17 UTC --- > (In reply to comment #15) > > > Both value-numbering (FRE/PRE, that do not run after store motion :/) and > > DOM should figure this out. DOM only in theory, but at least in this simple > > case it should figure it out. Do you have a testcase that does not require > > your patches? > > On a pristine trunk I don't have the exact problem (since the equality in > comment 14 was created by my WIP), but I do have a similar problem where no > optimization can figure out that g_2_lsm == g_2. > > Here is a variation of the PR testcase: > > int g_1 = 1; > int g_2 = 0; > > int func_1(void) > { > int l; > for (l = 0; l < 1234; l++) > { > if (g_1) > return l; > else > g_2 = 0; > } > return 999; > } > > On pristine trunk, we get: > > # VUSE <.MEM_9(D)> > g_2_lsm.6_12 = g_2; <-- g_2_lsm = g_2 > if (pretmp.4_1 != 0) > goto <bb 4>; > else > goto <bb 3>; > > <bb 3>: > # .MEM_8 = VDEF <.MEM_9(D)> > g_2 = 0; > goto <bb 5>; > > <bb 4>: > # .MEM_16 = VDEF <.MEM_9(D)> > g_2 = g_2_lsm.6_12; <-- g_2_lsm == g_2!! > > This may actually be the problem in this PR. If we could figure out that > g_2_lsm == g_2, there would be no write to g_2 on the g_1!=0 arm of the > conditional. > > Should DOM be able to figure out that g_2_lsm == g_2 in this case as well? Ah, so its about the redundant store. I only recently added the ability to DOM to remove redundant stores, so it might not yet be perfect. And in this case it is because the store is still in a loop, thus a dominator based approach does not really work well.
