On Wed, 2013-11-20 at 11:07 +0100, Jan-Benedict Glaw wrote:
> On Wed, 2013-11-20 10:08:45 +0100, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> [...]
> > I wonder if there are any more cases like this missed... Could you
> > please check that? Something like:
> > 
> > egrep -w "ENTRY_BLOCK_PTR|EXIT_BLOCK_PTR" gcc/*.[ch] gcc/config/*.[ch]
> > gcc/config/*/*.{c,h,md}
> 
> No more uses, but 21 comment lines contain references to the macros.

Sorry about the mips breakage, and thanks for fixing it.

I went through the comment lines, rewording the ones where the meaning
was obvious to me.  Attached is a patch that does so; successfully
compiled stage1; OK for trunk? (these are just changes to comments, so
not sure a full bootstrap is necessary).

There are three places the patch doesn't touch:

(A) cfgbuild.c (make_edges) has this comment:
  /* By nature of the way these get numbered, ENTRY_BLOCK_PTR->next_bb block
     is always the entry.  */
where the meaning wasn't immediately clear to me - what is the second
"entry" here?  (I haven't looked in detail at the algorithm).

FWIW the wording of this comment came from r53804:

  2002-05-23  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>

       * bb-reorder.c [...]:  Use FOR_EACH_BB macros to iterate over
basic block chain.
       [...]
       * cfgbuild.c [...]: Likewise.

which made this change to the comment:
-  /* By nature of the way these get numbered, block 0 is always the
entry.  */
+  /* By nature of the way these get numbered, ENTRY_BLOCK_PTR->next_bb
block
+     is always the entry.  */

(B) graphite-scop-detection.c (scopdet_basic_block_info) has:
  /* XXX: ENTRY_BLOCK_PTR could be optimized in later steps.  */
where the meaning isn't clear to me - whether this is a note about a
possible further optimization, or a warning that the entry could be
changed.

(C) tree-cfg.c (move_sese_region_to_fn): line 6899 has:
     FIXME, this is silly.  The CFG ought to become a parameter to
     these helpers.  */
where cfun is perhaps being unecessarily manipulated, and perhaps we
could actually gain a speedup from the macro removal work; if so, this
feels like a followup patch.

Comment-fixing patch follows.