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

[Chandler Carruth via llvm-commits]

On Tue, Aug 16, 2016 at 10:12 PM Daniel Berlin via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

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

Yea, I only did minimal work to avoid redundant calls to relatively
heavyweight predicates like isSafeToSpeculativelyExecute. Probably the most
that could be warranted here.

I'm much more interested in the avoidance of a quadratic failure mode.


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

FWIW, and as a side note, I used to really be interested in figuring out
the "right" API for an LLVM worklist.

I've mostly convinced myself this is hopeless. Most worklists that *really*
matter have highly specialized properties that they can and should exploit
to maximize efficiency. As a classic example, here and in many other places
I have had to avoid using SetVector just so that I can differently handle
the visited set from the worklist vector. This stuff keeps coming up, and I
no longer think there is a really beautiful generalization here.

What I *do* think we need lots of are the building blocks. Really good
sets, vectors, setvectors, mapvectors, and other primitives. We should
probably get a vector for which objects with an obvious null state can be
"GC"ed off the front whenever a grow would trigger walking the vector
anyways. We should also probably get a double stack at some point.

Then we should just make sure that the patterns for combining these in
common was are clean and well understood.

That's my best feeling for how to handle this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160817/9f6aab5b/attachment.html>