[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.