On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng <amker.ch...@gmail.com> wrote: > Hi, > As discussed at thread > "http://gcc.gnu.org/ml/gcc/2012-04/msg00396.html";, I am trying a patch > now. > The problem here is I have to go through all basic block from > "sink_from" to "sink_to" to check whether > the memory might be clobbered in them. > Currently I have two methods: > 1, do fully data analysis to compute the "can_sink" information at > each basic block, which means whether > we can sink a load to a basic block; > 2, just compute the transitive closure of CFG, and check any basic > block dominated by "sink_from" and can > reach "sink_to" basic block; > > The 2nd method is an approximation, simpler than method 1 but misses > some cases like: > > L1: > load x > L2: > using x > L3: > set x > goto L1 > > In which, "load x" should be sunk to L2 if there is benefit. > > I measured the number of sunk loads during bootstrap gcc for x86, > there are about 732 using method 1, while only 602 using method 2. > > So any comment on this topic? Thanks very much.
I don't understand method 2. I'd do start at the single predecessor of the sink-to block foreach stmt from the end to the beginning of that block if the stmt has a VDEF or the same VUSE as the stmt we sink, break (continue searching for VDEFs in predecessors - that now gets more expensive, I suppose limiting sinking to the cases where the above finds sth would be easiest, even limiting sinking to never sink across any stores) walk the vuse -> vdef chain, using refs_anti_dependent_p to see whether the load is clobbered. But I'd suggest limiting the sinking to never sink across stores - the alias memory model we have in GCC seriously limits these anyway. How would the numbers change if you do that? Richard. > -- > Best Regards.
