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] basic-block.h: Clean up FOR_EACH_EDGE.


Hi Jeff,

> > 	* basic-block.h (ei_cond): New.
> > 	(FOR_EACH_EDGE): Call ei_cond.
> Basically OK.  Though it seems to me ei_cond should really return a
> bool rather than an int.

The use of int was actually intentional.  If I use bool, I don't get
an expected (rather critical) jump threading.

Here is what happens if we make the return type being bool.  ei_cond
is inlined into the user of FOR_EACH_EDGE .  After the second DCE,
which is after the first DOM, I get

<L35>:;   // The then arm of the "if" statement in ei_cond
  :
  :
  :
  e = D.16009_132;
  goto <bb 20> (<L44>);

<L43>:;   // The else arm of the "if" statement in ei_cond
  e = 0B;

  # D.15985_32 = PHI <1(18), 0(19)>;
<L44>:;
  D.13342_107 = (unsigned char) D.15985_32;  // Ugh
  if (D.13342_107 != 0) goto <L25>; else goto <L45>;

Notice that we don't thread through <L44> because the threading
opportunities are blocked by the cast to unsigned char.
Unfortunately, this <L44> survives through the entire tree
optimizations.

If I use int, DOM threads through <L44> as expected.

It may not be a good idea for ei_cond to cover up an optimizer
deficiency by using int instead of bool, but I just wanted to let you
know what's going on.

Kazu Hirata


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