This is the mail archive of the gcc@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]

record_effective_endpoints


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.


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