[llvm-commits] PATCH: Fix quadratic behavior in PR12652
Chandler Carruth
chandlerc at gmail.com
Fri Jul 6 16:01:31 PDT 2012
On Fri, Jul 6, 2012 at 3:51 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
> On Jul 6, 2012, at 3:40 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>
> I still think we should likely make join() use this code because we should
> make it handle that input pattern efficiently, but fall back on something
> that isn't super-linear when it hits edge cases.
>
>
> How about sticking the merge state in a (local) class:
>
> class LIMerger {
> NewRanges, …
> public:
> LIMerger(LiveInterval &LHS, SlotIndex StartPos);
> void add(SlotIndex From, SlotIndex To, VNInfo *VNI);
> void finish();
> };
>
> That interface could readily be used by all three clients, and you don't
> clutter up the code with value mapping stuff.
>
I'd love an interface that doesn't involve the value mapping stuff...
The annoying thing is that exposing an interface like this makes the
looping logic extremely hard to read (for me at least). In the end, I had
an easier time with a few special cases in the inside of the loop with
comments.
That said, it could work. However:
> The add method can require disjoint, increasing segments:
>
One of the useful things to consolidate *is* the merging logic though.
The other thing that's tricky is that the merging logic can do very
surprising things because it has to remove elements from the LHS that are
subsumed by the merged entry. That was actually what led to the original
bad behavior.
I'm still looking at how best to write the code to make the cases where
size doesn't change, or only ever decreases, fast.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120706/4041a7ee/attachment.html>
More information about the llvm-commits
mailing list