On Mon, Mar 14, 2016 at 04:32:06PM -0600, Jeff Law wrote: > On 03/11/2016 03:02 AM, Richard Biener wrote: > > > > > >For the other part I noticed a few things > > 1) having a bitmap_count_ior_bits () would be an improvement > Yea, I almost built one. That's easy enough to add. > > > 2) you might end up with redundant work(?) as you are iterating > > over SSA name coalesce candidates but look at partition conflicts > We'd have redundant work if the elements mapped back to SSA_NAMEs which in > turn mapped to partitions which appeared as a coalescing pair already. But > there's no way to know that in advance. > > This is mitigated somewhat in the next version which computes the conflict > sizes lazily when the qsort comparison function is given two conflict pairs > with an equal cost. > > > > > 3) having this extra heuristic might be best guarded by > >flag_expensive_optimizations > Perhaps. I don't see this tie breaker as being all that expensive. But I > won't object to guarding with flag_expensive_optimizations. > > > as it is a quite expensive "tie breaker" - maybe even improve things > >by first sorting > > after cost and then only doing the tie breaking when necessary, re-sorting > > the > > sub-sequence with same original cost. It may also be enough to only > > perform > > this for "important" candidates, say within the first 100 of the function > > or so > > or with cost > X. > The problem with this is qsort's interface into the comparison function has > a terribly narrow API and I don't think we want to rely on qsort_r. In fact > that's the whole reason why I didn't do lazy evaluation on the conflict > sizes initially. > > To work around the narrow API in the comparison function we have to either > store additional data in each node or have them available in globals. The > former would be horribly wasteful, the latter is just ugly. I choose the > latter in the lazy evaluation of the conflicts version.
its a bit ugly in C++98, but you can give std::sort a random object with operator () to compare with. Trev
