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
