[PATCH] D23396: [Assumptions] Make collecting ephemeral values not quadratic in the number of assume intrinsics.

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 16 22:12:27 PDT 2016


FWIW: the traditional solution to this problem is the "double stack"
approach (really a double queue), which is maintaining a current and next
worklist.
After evaluating worklist algorithms and datastructures on  tons and tons
and tons and tons testcases (and looking at the behaviors of all the
existing worklists), this is what ended up being the final solution in gcc.

The practical performance and memory differences between the various  data
structures are ... essentially nil on most cases.

Now, the algorithms and what tricks you use to avoid revisiting stuff and
ordering, that matters.
(probably not so much here though :P)

Whether it's worth making a new ADT for worklists, i'd only do it if we
thought it had API and maintenance benefits, because IMHO it's unlikely to
have any significant performance benefits.





On Tue, Aug 16, 2016 at 8:18 PM, Dean Michael Berris via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> dberris added a subscriber: dberris.
> dberris added a comment.
>
> How hard would it be to amortize the removal from the queue grows to a
> certain size? I ask because at some point the cost of copying around chunks
> of memory when a vector grows might outweigh the cost of just regularly
> trimming the queue if there are visited/stale entries at the beginning to
> the "current head" iterator.
>
>
> https://reviews.llvm.org/D23396
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160816/e4ea85b9/attachment.html>


More information about the llvm-commits mailing list