[PATCH] ScheduleDAGInstrs::buildSchedGraph() rewritten.

hfinkel at anl.gov hfinkel at anl.gov
Fri Feb 27 05:52:01 PST 2015


In http://reviews.llvm.org/D7850#131115, @jonpa wrote:

> Minor fixes, as requested.
>
> Regarding SUList and use of std::list:
>
> I have tried a few options to using std::list for SUList, but unfortunately I cannot find any faster alternative:
>
> - SparseSet: Quite memory expensive, considering that a map of max size MaxS, will in the worst case contain MaxS lists of SUs, each of size one but with the SparseSet::Universe of SUnits.size(). This will certainly also degrade cache performance. Furthermore, this data structure does not guarantee iteration in the order of insertion, after an element has been erased. This is needed to make repeated FIFO order reductions of the list.
> - CircularSmallVector: I tried to derive a vector from SmallVector that was reducible in FIFO order without needless re-allocation. The class uses Head and Tail indexes into the vector and instead of erasing elements, a Tail is introduced, which may wrap around after repeated calls to reduce(). It was however marginally slower than std::list.
> - SmallVector: Just using a vector was of course very slow, due to all the copying during reductions.
>
>   FIFO order reduction should be desireble, as in a region with many unknown stores and loads, it would probably be better to avoid close dependencies rather than between SUs with very different NodeNums (far apart in MBB). It does not matter in which order the list is iterated over, and indexed access is not needed.
>
>   If anyone has a good idea on this, or wants to see my circular vector, let me know. Until then, std::list remains.


Okay, fair enough. I'd think that what you really want is a linked list stored in approximately-cache-line-sized groups. Unfortunately, we don't have this data structure. What you have certainly seems like a significant improvement (std::list or not), so I'd not insist on a different data structure now.


http://reviews.llvm.org/D7850

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list