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


> 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;
>       else
> 	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?

-- 
Eric Botcazou


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