Bin Cheng wrote: > I have already worked out an initial patch to extend the pass in two ways: > 1. extend it into a global pass; > 2. make it handle const propagation;
You'll find this is not quite so easy as what you describe. Changing constants after reload is harder and less effective than before, because only legitimate constants can be propagated, and you'd have to check at each use site whether the constant is legitimate. For copy propagation, the same applies. The current approach of cprop_hardreg is not really limited to single basic blocks. It runs on extended basic blocks, but its strategy is quite stupid. You may find that you can solve the problem you're trying to solve by just teaching regcprop.c to process blocks in reverse post order instead of using FOR_EACH_BB. You don't even have to compute RPO, it is already available via df_get_postorder(DF_FORWARD. I think you should try the above approach first, before over-complicating things. Bonus points if you can teach inverted_post_order_compute to prefer hot paths. > In fact, the code change can be very small by reusing facilities in > cprop.c as described below: > 1. compute cprop_avin/cprop_avout by calling function like > compute_cprop_data in cprop.c. This will be way too expensive. These routines are optimized for problems with registers with short DF_REG_DEF_CHAINs, and they don't handle hard registers at all. After reload, DF_REG_DEF_CHAINs can be very long, and the addressing modes may differ from one def/use to the next. This isn't handled in cprop either. cprop.c simply ignores hard registers. It should stay that way, too. > 2. use cprop_avin[bb] to initialize the global propagation information > for each basic block. No, you'd have to compute block local properties yourself. You can use lcm.c:compute_available() though. > 3. do propagation as usual by calling copyprop_hardreg_forward_1. > 4. make cprop_hardreg do const propagation with some other trivial > modifications. You'll find these modifications will not be trivial. Ciao! Steven
