This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Rename across basic block boundaries
Bernd Schmidt <bernds@codesourcery.com> writes:
> On 09/01/11 16:16, Richard Sandiford wrote:
>> Bernd Schmidt <bernds@codesourcery.com> writes:
>>> On 08/26/11 14:57, Richard Sandiford wrote:
>>>> Wouldn't a reverse post-order (inverted_post_order_compute) allow even
>>>> more pre-opening (as well as being less code)?
>>>
>>> I can't really tell from the comments what that function is supposed to
>>> produce.
>>
>> Sorry, I thought it was supposed to produce a reverse postorder, but...
>>
>>> I've made a change to use it to order the bbs, but that made rr
>>> visit basic blocks without seeing any of their predecessors first,
>>
>> ...I guess not. :-) pre_and_rev_post_order_compute should though.
>> Could you try that instead?
>
> That seems to work for me.
Looks good to me. Maybe here:
> + /* The order in which we visit blocks ensures that whenever
> + possible, we only process a block after at least one of its
> + predecessors, which provides a "seeding" effect to make the logic
> + in set_incoming_from_chain and init_rename_info useful. */
> +
> + for (i = 0; i < n_bbs; i++)
> + {
> + basic_block bb1 = BASIC_BLOCK (inverse_postorder[i]);
> + struct bb_rename_info *this_info = rename_info + i;
> [...]
> + if (bb1->aux == NULL)
> + continue;
it would be better to use:
this_info = (struct bb_rename_info *) bb1->aux;
if (this_info == NULL)
continue;
so that we don't care which order the rename_info array is. You could
then keep the original form of the first loop:
/* Gather some information about the blocks in this function. */
rename_info = XCNEWVEC (struct bb_rename_info, n_basic_blocks);
ri_index = 0;
FOR_EACH_BB (bb)
{
struct bb_rename_info *ri = rename_info + ri_index;
ri->bb = bb;
ri->n_preds = EDGE_COUNT (bb->preds);
bb->aux = ri;
ri_index++;
}
OK with me whichever.
Richard