This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix comments that refer to ENTRY_{BLOCK|EXIT}_PTR
- From: Jeff Law <law at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>, Jan-Benedict Glaw <jbglaw at lug-owl dot de>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc-patches at gcc dot gnu dot org, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Wed, 20 Nov 2013 11:28:19 -0700
- Subject: Re: [PATCH] Fix comments that refer to ENTRY_{BLOCK|EXIT}_PTR
- Authentication-results: sourceware.org; auth=none
- References: <20131120090429 dot GT30563 at lug-owl dot de> <CABu31nOxDcuTvsGVU6YrLmd_ZEkuon8hiUNMoPk466F5WAkOGA at mail dot gmail dot com> <20131120100703 dot GV30563 at lug-owl dot de> <1384967011 dot 11568 dot 154 dot camel at surprise>
On 11/20/13 10:03, David Malcolm wrote:
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).
Yea, if you're just changing a comment, just compiling enough to ensure
you didn't make a goof like forgetting to close the comment is fine.
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).
Hmm, I think "the entry" should be "the exit". My recollection is
ENTRY_BLOCK is block #0 and EXIT_BLOCK is block #1. But that would mean
we're making a edge from the entry to the exit?!?
(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.
Me neither. I try to avoid the graphite bits.
(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.
That could be a follow-up. Not sure if it really buys us much since
we're going to have to extract the CFG from the target cfun anyway. I
guess we avoid pushing/popping them.
The downside is you'll have to pass the CFG into all those make_edge
calls, which 99.9% of the time is pointless.
As for the patch itself, it's fine.
jeff