public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/37684]  New: [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
@ 2008-09-30 16:34 hjagasia at gcc dot gnu dot org
  2008-09-30 16:36 ` [Bug c/37684] " hjagasia at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: hjagasia at gcc dot gnu dot org @ 2008-09-30 16:34 UTC (permalink / raw)
  To: gcc-bugs

When translate_clast is called for a scop, scalar definitions are optimized out
and hence any subsequent uses of those scalars, outside the scop, represents a
problem. Also as code is generated for a scop, basic blocks in the scop are
moved around such that the block which contains the definition of a scalar no
longer dominates the basic block outside the scop which contains a use of that
scalar.

Attached reduced testcase block-3.c (derived from cpu2006-401.bzip2-bzlib.c)
fails in gloog->verify_ssa->verify_use at below:
>>>
  else if (bb != def_bb
           && !dominated_by_p (CDI_DOMINATORS, bb, def_bb))
    {
      error ("definition in block %i does not dominate use in block %i",
             def_bb->index, bb->index);
      err = true;
    }
>>>
Before translate_clast is called, here is an excerpt from the function:
<bb 3>:
  # SMT.48_24 = PHI <SMT.48_20(4), SMT.48_18(2)>
  # i_28 = PHI <i_10(4), 0(2)>
  # SMT.49_29 = PHI <SMT.49_21(4), SMT.49_19(2)>
  # SMT.48_20 = VDEF <SMT.48_24>
  # SMT.49_21 = VDEF <SMT.49_29>
  s_5->inUse[i_28] = 0;
  i_10 = i_28 + 1;
  if (i_10 <= 255)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  goto <bb 3>;

<bb 5>:

<bb 6>:
  # VUSE <SMT.48_20, SMT.49_21>
  D.1656_11 = s_5->blockNo;
  D.1657_12 = D.1656_11 + 1;
  # SMT.48_22 = VDEF <SMT.48_20>
  # SMT.49_23 = VDEF <SMT.49_21>
  s_5->blockNo = D.1657_12;
  return;

At this point bb 3 which contains the VDEF for SMT.48_20 and SMT.49_21
dominates bb 6 which contains the VUSE for the same. The VDEF is associated
with s_5->blockNo and the VUSE with s_5->inUse[i_28].

After translate_clast is called, here is an excerpt from the function:
BZ2_bzCompressInit (struct bz_stream * strm, int blockSize100k, int verbosity,
int workFactor)
{
  struct EState * D.1728;
  int D.1725;
  int D.1726;
  int D.1727;
  int graphiteIV.63;
  int graphiteIV.62;
  Int32 pretmp.52;
  int D.1656;
  int D.1657;
  Int32 i;
  struct EState * s;
  void * D.1643;
  void * D.1642;
  void * (*<T494>) (void *, int, int) D.1641;

<bb 2>:
  # VUSE <SMT.47_14(D), SMT.49_15(D)>
  D.1641_2 = strm_1(D)->bzalloc;
  # VUSE <SMT.47_14(D), SMT.49_15(D)>
  D.1642_3 = strm_1(D)->opaque;
  # SMT.47_17 = VDEF <SMT.47_14(D)>
  # SMT.48_18 = VDEF <SMT.48_16(D)>
  # SMT.49_19 = VDEF <SMT.49_15(D)>
  D.1643_4 = D.1641_2 (D.1642_3, 304, 1);
  s_5 = (struct EState *) D.1643_4;

<bb 7>:
  # graphiteIV.62_13 = PHI <0(2), graphiteIV.62_6(8)>
  graphiteIV.62_6 = graphiteIV.62_13 + 1;
  if (graphiteIV.62_6 <= 3)
    goto <bb 11>;
  else
    goto <bb 5>;

<bb 11>:
  graphiteIV.63_9 = graphiteIV.62_13 * 64;

<bb 9>:
  # graphiteIV.63_27 = PHI <graphiteIV.63_9(11), graphiteIV.63_25(10)>
  # SMT.48_24 = PHI <>
  # SMT.49_29 = PHI <>
  graphiteIV.63_25 = graphiteIV.63_27 + 1;
  D.1725_26 = graphiteIV.62_13 * 64;
  D.1726_30 = D.1725_26 + 63;
  D.1727_31 = MIN_EXPR <D.1726_30, 255>;
  if (graphiteIV.63_25 <= D.1727_31)
    goto <bb 3>;
  else
    goto <bb 8>;

<bb 10>:
  goto <bb 9>;

<bb 8>:
  goto <bb 7>;

<bb 3>:
Invalid sum of outgoing probabilities 0.0%
Invalid sum of incoming frequencies 25, should be 9900
  D.1728_32 = (struct EState *) D.1643_4;
  D.1728_32->inUse[graphiteIV.63_27] = 0;
  goto <bb 10>;

<bb 4>:
Invalid sum of incoming frequencies 0, should be 9800

<bb 5>:

<bb 6>:
  # VUSE <SMT.48_20, SMT.49_21>
  D.1656_11 = s_5->blockNo;
  D.1657_12 = D.1656_11 + 1;
  # SMT.48_22 = VDEF <SMT.48_20>
  # SMT.49_23 = VDEF <SMT.49_21>
  s_5->blockNo = D.1657_12;
  return;

}

During translate_clast the scop is transformed and the scalar VDEFS for
SMT.48_20, SMT.49_21 are removed by graphite. Also bb 3 no longer
dominates bb 6.


-- 
           Summary: [graphite] basic block containing VDEF of a scalar does
                    not dominate basic block containing VUSE of the same
                    scalar
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: hjagasia at gcc dot gnu dot org
        ReportedBy: hjagasia at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-12-03 20:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-30 16:34 [Bug c/37684] New: [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar hjagasia at gcc dot gnu dot org
2008-09-30 16:36 ` [Bug c/37684] " hjagasia at gcc dot gnu dot org
2008-09-30 16:41 ` [Bug tree-optimization/37684] " hjagasia at gcc dot gnu dot org
2008-10-03 21:12 ` spop at gcc dot gnu dot org
2008-10-03 21:12 ` spop at gcc dot gnu dot org
2008-11-03 16:45 ` spop at gcc dot gnu dot org
2008-11-03 16:46 ` spop at gcc dot gnu dot org
2008-12-03 20:55 ` spop at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).