[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2012-09-20 07:43:56 UTC ---
On Wed, 19 Sep 2012, aldyh at gcc dot gnu.org wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173
> 
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |amacleod at redhat dot com,
>                    |                            |dnovillo at gcc dot
>                    |                            |gnu.org, rguenth at gcc dot
>                    |                            |gnu.org
> 
> --- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-19 19:44:14 UTC ---
> Richi, Diego.  Perhaps you can shed light on this.
> 
> Here we have a loop unroll that triggers a "virtual def operand missing..." for
> a GIMPLE_TRANSACTION:
> 
>     int vec[500];
> 
>     void func()
>     {
>         __transaction_relaxed
>         {
>           vec[123] = 456;
>         }
>     }
> 
>     main()
>     {
>       int i;
>       for(i = 0; i < 10; ++i)
>         func();
>     }
> 
> The unroller wants to unroll into something like:
> 
>   <bb 2>:
>   # .MEM_6 = VDEF <.MEM_13>
>   __transaction_relaxed        <-- PROBLEMATIC INSN (VDEF's)
> 
>   <bb 3>:
>   # .MEM_9 = VDEF <.MEM_59>
>   vec[123] = 456;
>   # .MEM_2 = VDEF <.MEM_9>
>   __builtin__ITM_commitTransaction ();
> 
>   <bb 4>:
>   ivtmp_14 = 9;
>   # .MEM_11 = VDEF <.MEM_13>
>   __transaction_relaxed
> 
>   <bb 5>:
>   # .MEM_18 = VDEF <.MEM_59>
>   vec[123] = 456;
>   # .MEM_19 = VDEF <.MEM_18>
>   __builtin__ITM_commitTransaction ();
> 
> etc etc etc.
> 
> Putting aside how incredibly inefficient this is... (We should be duplicating
> the vector store, not the entire transaction)...
> 
> The problem here is that, after unrolling, the VDEF of the problematic insn is
> .MEM_6, but the DEF_OP of the insn is .MEM_59.  So gimple_vdef() !=
> gimple_vdef_op() and we trigger a "virtual def operand missing for stmt".
> 
> The problem is that the unroller's call to gimple_duplicate_bb() will make a
> copy of the problematic instruction, maintaining its gimple_vdef, but changing
> all its def_ops from under us, thus making gimple_vdef() != gimple_vdef_op().

Setting a DEF will change the vdef.  If it does not, the stmt was
not updated properly.

> Before loop unrolling we have this snippet that is about to be unrolled:
> 
>   <bb 3>:
>   # .MEM_13 = PHI <.MEM_8(6), .MEM_3(D)(2)>
>   # ivtmp_1 = PHI <ivtmp_10(6), 10(2)>
>   # .MEM_6 = VDEF <.MEM_13>
>   __transaction_relaxed
> 
> After loop unrolling the above remains unchanged, but the following is inserted
> *before* bb 3.  [Note, the following is after update_ssa(TODO_update_ssa), but
> before cleanup_tree_cfg() for clarity.]
> 
>  <bb 8>:
>   # .MEM_12 = PHI <.MEM_3(D)(2)>
>   # ivtmp_5 = PHI <10(2)>
>   # .MEM_6 = VDEF <.MEM_13>     <-- *************************** -->
>                   ^^^^^^^^^^^^  <-- shouldn't this be <.MEM_12> ?????
>                                 <-- *************************** -->

Yes.

>   __transaction_relaxed
> ...
> ...more unrolling
> ...
>  <bb 40>:
>   # .MEM_57 = PHI <.MEM_8(39)>
>   # ivtmp_58 = PHI <ivtmp_10(39)>
>   # .MEM_53 = VDEF <.MEM_13>    <-- ************************** -->
>                                 <-- shouldn't this be <.MEM_57> ????
>                                 <-- ************************** -->

Yes.

>   __transaction_relaxed
> ...
> ...
>  <bb 3>
>  ..
> 
> Notice that both BB8 and BB40 invalidate MEM_13 in its virtual definition. 
> Shouldn't the VDEF<.MEM_13> be rewritten as I have indicated above?  Especially
> since now .MEM_13 is defined much further down in bb 3:
> 
> <bb 8>
>     # invalidates VDEF<.MEM_13>
> ...
> <bb 40>
>     # invalidates VDEF<.MEM_13>
> ..
> <bb 3>
>     # define .MEM_13  = ....
> 
> It seems gimple_duplicate_bb() renames all the phis and the operands, but does
> not update the VDEF's for the transaction. Gimple_duplicate_bb() says it
> doesn't maintain SSA form, so I assume this in on purpose (?).  So how is this
> supposed to be cleaned up?  Or is this even the problem?

The problem must be in the IL before unrolling I believe.

Richard.