This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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