This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Decompose gimplify_expr


On Wed, 3 Aug 2005, Steven Bosscher wrote:

> On Wednesday 03 August 2005 11:32, Zdenek Dvorak wrote:
> > Hello,
> >
> > > > > > In any case, I don't intend to implement any complicated
> > > > > > optimizations. I definitely will avoid any "special case handling";
> > > > > > if the optimization is too complicated, it is hardly worth doing
> > > > > > at the expansion time.  I will be considering only simple
> > > > > > optimizations like unreachable code removal and constant
> > > > > > propagation that have a good chance to be very useful and save
> > > > > > significant amount of memory and compile time (especially on code
> > > > > > that uses macros a lot).\
> > > > >
> > > > > I will simply note that we have *already* run into issues because
> > > > > things like "constant propagation" were added to cleanup_cfg.  (It
> > > > > ends up causing us to need to update ssa in some cases that it
> > > > > doesn't do, and shouldn't have to, since it's a fricking cfg cleanup
> > > > > pass)
> > > >
> > > > constant propagation is not performed anywhere in cfg cleanup.
> > >
> > > Constant propagation is performed in tree_merge_blocks when the PHI
> > > argument is a constant.  IIRC Richard Guenther had an example of this
> > > actually happening in one of his test cases.
> >
> > OK, I forgot on this.  Nevertheless, the constant propagation itself of
> > course does not cause need to update SSA;
> 
> It does in Richi's case because ARRAY_REF<array, ssa_name> does not need
> SFTs, but ARRAY_REF<array,constant> does if the constant is smaller than
> the threshold he has for structure alias analysis for arrays.
> (I guess Richard can explain it best himself, so he's in the CC: now.)

Ok, I digged out a tree-dump after the fix, cunroll causes the problem
for the simple testcase

int x[2];
void foo(void)
{
  int i;
  for (i=0; i<2; ++i)
    x[i] = i;
}

and we end up with (correctly)

foo ()
{
  unsigned int ivtmp.29;
  int pretmp.28;
  int i;
  int i.0;

<bb 0>:
  #   SFT.2_16 = V_MUST_DEF <SFT.2_5>;
  x[0] = 0;
  i_19 = 1;
  ivtmp.29_20 = 1;

Invalid sum of incoming frequencies 5000, should be 10000
  # ivtmp.29_2 = PHI <ivtmp.29_20(0)>;
  # SFT.2_15 = PHI <SFT.2_16(0)>;
  # SFT.1_14 = PHI <SFT.1_6(0)>;
  # i_13 = PHI <i_19(0)>;
<L0>:;
  #   SFT.1_8 = V_MAY_DEF <SFT.1_14>;
  #   SFT.2_9 = V_MAY_DEF <SFT.2_15>;
  x[i_13] = i_13;
  i_10 = i_13 + 1;
  ivtmp.29_3 = ivtmp.29_2 - 1;
  return;

}


where the bug was that we had

<bb 0>:
  #   SFT.2_16 = V_MUST_DEF <SFT.2>;
  x[0] = 0;

instead (or using an SSA name before it's definition - I don't
remember exactly, and I don't have a broken compiler lying around
anymore).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]