[llvm-commits] Review request: dominance frontier computation speedup

Chris Lattner clattner at apple.com
Sun Nov 28 12:04:58 PST 2010


On Nov 24, 2010, at 1:21 PM, Cameron Zwarich wrote:

> On Nov 24, 2010, at 3:21 PM, Jakob Stoklund Olesen wrote:
> 
>> This is actually in the non-templated SmallPtrSetImpl::Grow function.
>> 
>> I don't know which method was used to arrive at the number 128. The Small* classes are actually not designed to be compact despite the name. They are designed to work well as stack objects, avoiding malloc for typical loads.
>> 
>> Presumably, the large initial size was chosen to avoid multiple reallocations and re-hashings as the set grows. When a SmallPtrSet is used as a one-off stack object, that is the right thing to do.
> 
> We could template it to add this parameter, so the common case can be shared, but that's probably not a great idea. 

Jakob's right, SmallPtrSet was really intended to be a stack object.  Typically if you overflow a stack object, it is because you're in the "large" case, and you might as well go for one big allocation to avoid the reallocation.

However, I guess it does make sense for "small" objects to be used in (already expensive) node-based containers like std::map.  I wouldn't be opposed to adding a template argument to control this, and have it get passed down as a bool to grow().

>> Perhaps there exists a third data structure that would be both compact and fast? Is it necessary to be able to enumerate a node's dominance frontier? Is it enough to be able to answer "Is A in the dominance frontier of B?"
> 
> Both the IDF algorithm and RegionInfo need to iterate over the elements of DFs. It would be nice to use SmallSet instead, though.

Another concern: does anything depend on iteration over DF sets being in pointer order?  SmallPtrSet doesn't provide stable iteration.

There are other low-hanging opportunities to speed up the existing dom frontiers implementation: the std::set in compareDomSet can trivially be converted to SmallPtrSet (and ideally moved out of line :) for example.

In any case, your patch looks good to me Cameron, please apply!  Please do look into the grow() issue though.

-Chris 







More information about the llvm-commits mailing list