[PATCH] ScheduleDAGInstrs::buildSchedGraph() rewritten.

David Blaikie dblaikie at gmail.com
Fri Feb 27 09:18:14 PST 2015


On Fri, Feb 27, 2015 at 5:52 AM, hfinkel at anl.gov <hfinkel at anl.gov> wrote:

> 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.


Not quite what you described, but std::deque?

(side note: deriving from standard containers seems a bit... not nice - I'd
prefer composition, but I haven't looked at the patch in any detail)


> 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/
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150227/a722eca3/attachment.html>


More information about the llvm-commits mailing list