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

Re: [PATCH] Fix four bugs in combine


> It is only a sufficient condition.

OK, thanks.

> Since the blocks are visited in order of index, the data at the end of
> the previous block is still valid if the new block has the previous
> block as the predecessor.  I had missed the case of EXIT_BLOCK
> sitting between ENTRY_BLOCK and its successor.
>
> For this particular bug, I'd rather specialize
> "|| single_pred (this_basic_block) == ENTRY_BLOCK"
> since we know the ENTRY_BLOCK is not processed by
> FOR_EACH_BB.  So we can keep the ticks monotonic.

I'd rather shield again the code from the (order of) basic block indexes, as 
it was before, this seems more robust.  So I'd do 

/* Reset to label_tick for each extended basic block in scanning order.  */

static int label_tick_ebb_start;

[...]

  label_tick = label_tick_ebb_start = 1;

  setup_incoming_promotions (first);
[...]
  label_tick++;

and then use Adam's idea of reusing the BB of the previous iteration:

  /* If the preceding basic block is not our single predecessor, we can
     be reached from elsewhere so it's a new extended basic block.  */
  if (!single_pred_p (this_basic_block)
      || single_pred (this_basic_block) != last_basic_block)
    label_tick_ebb_start = label_tick;

  last_basic_block = this_basic_block;

-- 
Eric Botcazou


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