Bernd Schmidt <ber...@codesourcery.com> writes: > On 09/01/11 16:16, Richard Sandiford wrote: >> Bernd Schmidt <ber...@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