This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix four bugs in combine
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Adam Nemet <anemet at caviumnetworks dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 7 Oct 2009 16:22:52 +0200
- Subject: Re: [PATCH] Fix four bugs in combine
- References: <firstname.lastname@example.org>
> This patches fixes four related bugs in combine. Some of these might have
> been introduced by the cfglayout conversion, I am not sure though.
No, fortunately they are far more recent (r145283).
> 1. To decide whether to start a new EBB, the code goes by basic-block
> numbers; a block is considered to be part of the current EBB if the
> basic-block number is one more than the previous and the block has only one
> predecessor. This does not hold between the ENTRY_BLOCK (0) and the first
> block (2) due to EXIT_BLOCK being number 1.
> Since incoming promotions get the tick from the initial tick (0), they
> would no longer be valid in the first block.
> I fixed this by using the label tick of the block from the previous
> iteration of the BB loop.
> 2. Since everything inside reg_stat is initialized to zero. It's
> unfortunate to start the tick value at 0. For example in
> record_value_for_reg we invalidate the value of a promotion:
> /* Now update the status of each register being set.
> If someone is using this register in this block, set this register
> to invalid since we will get confused between the two lives in this
> basic block. This makes using this register always invalid. In cse,
> we scan the table to invalidate all entries using this register, but this
> is too much work for us. */
> for (i = regno; i < endregno; i++)
> rsp = VEC_index (reg_stat_type, reg_stat, i);
> rsp->las->int_set_label = label_tick;
> if (!insn
> || (value && rsp->last_set_table_tick >= label_tick_ebb_start))
> rsp->last_set_invalid = 1;
> rsp->last_set_invalid = 0;
> because both rsp->last_set_table_tick (unmodified at this point) and
> label_tick_ebb_start are 0.
> I changed label_ticks to start from 1.
> 3. setup_incoming_promotions() calls record_value_for_reg, which uses
> label_tick and label_tick_ebb_start. Hence we need to initialize the value
> of label_tick_ebb_start before calling setup_incoming_promotions in the
> first pass.
> 4. Same thing is broken WRT to label_tick and setup_incoming_promotions in
> the second pass.
That would probably work, but I don't like non-monotonically increasing ticks.
What about partially reverting r145283, i.e. turning back ticks into ticks,
and just comparing the indexes of the BBs to bump label_tick_ebb_start?