This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
record_effective_endpoints
- From: Kiran Kumar <kiran dot kumar at mindspeed dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 31 Mar 2003 10:29:00 -0500
- Subject: record_effective_endpoints
- References: <3E81E792.9E608125@mindspeed.com> <20030326180033.GA19016@artax.karlin.mff.cuni.cz>
Hi,
GCC marks effective end points of each
basic block before performing basic block
reordering (record_effetive_endpoints call)
---------------------
basic block N
insns in BB(N) ...
basic block N
notes
jump table header labels
addr_vec/addr_diff_vec related jump_insns
barriers
basic block N+1
insns in BB(N+1)
basic block N+1
---------------------
Looking at the code I figured out that those
dangling notes and labels between basic
blocks as shown in the above sequence get
attached to basic block 'N' and not basic block 'N+1'.
This may have serious implications on
front-ends which do not exactly layout actual
jump tables right next the tablejump instructions.
In such a case when basic block reordering wants
to rearrange blocks this would cause incorrect
movement, which would leave the jump table header
labels in the original place when the actual jump table
entries themselves move closer to table branch
instruction.
If I am correct in my analysis the
jump table header label, the addr_vec/addr_diff_vec
and the corresponding barrier if present have
to be associated with the basic block N+1 and
not basic block N.
I am not sure about other GCC specific notes
(with line number < 1) which exist between those
two basic blocks. May be they should still be
part of basic block N.
I guess in the case of C front-end this was never a
problem because both addr_vec and addr_diff_vec are emitted
right after the tablejump instruction leaving no
room for basic block reordering for such a movement.
Does anyone agree with my argument?
Best Regards,
Kiran.