[llvm-commits] PATCH: Expose the merge interface for LiveInterval and use it to speed up a few hot paths in LiveIntervalAnalysis

[Jakob Stoklund Olesen]

On Jul 15, 2012, at 5:00 AM, Chandler Carruth <chandlerc at gmail.com> wrote:

> These two callsites to addRange showed up as fairly hot, taking about 10% of some executions with many basic blocks and variables.

You mean the asan test case, right? It is important to pay attention to the performance of typical compilations which look very different.

> Exposing the merge interface and using it to batch each loop makes them vanish from the profile, dropping compilation time on one address sanitizer test case by 10%.

+    /// \brief Merge the specified array of LiveRanges into this interval.
+    ///
+    /// This merges with existing ranges as appropriate. Clients should use
+    /// this interface if potentially many ranges are going to be merged in
+    /// sequence rather than calling addRange repeatedly.
+    void mergeRanges(ArrayRef<LiveRange> Ranges);

The problem is, this interface exposes the innards of the LiveInterval representation and the merge algorithm. It doesn't fit the callers well, forcing them to copy their data structures just to fit the API. (And then the merge makes another copy).

It would be much better to wrap the merge algorithm state in a class with an add(start, end, valno) function.

That would also help solve the second problem: The ranges to merge must be sorted, but the callers only have almost-sorted lists. SlotIndex numbering follows layout which is not the same as MBB numbering. The kill lists are probably layout-ordered most of the time, but it is not an invariant being maintained but the LV updaters.

A merge algorithm class could easily detect ordering violations and restart itself. Restarting the merge is no slower than calling addRange(), and it will be very effective for the almost-sorted cases.

/jakob