[PATCH] D20178: Fix PR26055 - LiveDebugValues is very slow

[Daniel Berlin via llvm-commits]

On Wed, May 18, 2016 at 5:33 PM, Adrian Prantl <aprantl at apple.com> wrote:

> aprantl added a comment.
>
> In http://reviews.llvm.org/D20178#431100, @dberlin wrote:
>
> > Note: If the time bound on the version with N^2 inner loops is beyond
> what
> >  you want to do, happy to review the patch as-is and get it in, and we
> can
> >  just drop a comment about further improvement
>
>
> Thanks, I think it would be a good idea to make a cut here and land this
> revision in trunk as an intermediate step so we can use it as a basis for
> further improvements!
>
> Sounds good to me!
I'll do a second review just to make sure there is nothing obviously wrong.

Thanks for working so hard on this.

I'll keep working on it, but doing so takes time, and I keep getting
> distracted by other things.
>
>
That's my life!

> As for my progress: I'm done with my first iteration of rewriting
> transferRegisterDef() and it had almost no effect on my benchmark. This is
> because in my benchmark none of the variables survive the first basic
> block, which explains why I couldn't measure any improvements. I'll need to
> find a better benchmark to profile my bitvectorized transferRegisterDef()
> implementation.
>

interesting :)


>
> So where are the remaining 2 minutes spent? With some more profiling I
> figured that most of the time is spent in transferDebugValue(). In my
> benchmark OpenRanges has >5000 elements (mostly from inlined C++
> one-liners) so linearly iterating over all of them for every DEBUG_VALUE is
> very expensive. My idea is to exploit the sorted-ness of the map in the
> UniqueVector to only iterate over only over the elements that share the
> same DebugVariable.
>

Yeah.  equal_range is your friend.
You could also ilist the datastructure so they were all linked together
naturally.



> I'll post a separate review once I've got something presentable.
>
>
> Sounds good.


> http://reviews.llvm.org/D20178
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160518/c5e23f9a/attachment.html>