From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-401298-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 3618 invoked by alias); 19 Sep 2012 19:44:48 -0000
Received: (qmail 3560 invoked by uid 48); 19 Sep 2012 19:44:17 -0000
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
Date: Wed, 19 Sep 2012 19:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: aldyh at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: CC
Message-ID: <bug-52173-4-GpNaIJBiyr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52173-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52173-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-09/txt/msg01464.txt.bz2


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().

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> ?????
                                <-- *************************** -->
  __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> ????
                                <-- ************************** -->
  __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?