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]

cfg_layout_split_edge doesn't handle the general case correctly


Hello there,

While trying to use loop information in later stages of
the RTL level I have encountered a problem with cfg_layout_split_edge.
It turns out that this function is not correct in some cases.
according to the below lines, cfg_layout_split_edge adds the newly
created basic block after e->src, this is not correct when there
is at least one additional edge that is fallthru that is going out
of e->src.
  cfg_layout_split_edge (edge e)
  {
     edge new_e;
     basic_block new_bb =
     create_basic_block (e->src != ENTRY_BLOCK_PTR
                  ? NEXT_INSN (BB_END (e->src)) : get_insns (),
                  NULL_RTX, e->src);

Int he tree level (tree_split_edge) we try to put the new block before
e->src
first and check a similar put if our check fails we put the block after
e->src
without additional checking; see the following lines taken from
tree_split_edge:
   /* Place the new block in the block list.  Try to keep the new block
      near its "logical" location.  This is of most help to humans looking
      at debugging dumps.  */
   for (e = dest->pred; e; e = e->pred_next)
     if (e->src->next_bb == dest)
       break;
   if (!e)
     after_bb = dest->prev_bb;
   else
     after_bb = src;

The above makes the CFG inconsistent, and calling commit_edge_insertions in
that
situation causes an ICE (this was the case when I tried to use
loop_optimizer_init
inside SMS, in which I use commit_edge_insertions).

Is there something wrong in my understanding of the above?
Do we need a fix for this?

Thanks,
Mostafa.







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