[PATCH] D15857: [InstCombine] Defend against worst-case exponential execution time

[James Molloy via llvm-commits]

Hi,

Yes. Yes it would. That's a good idea and in fact we only ever need to
visit any single OR once and once only. We can use a simple set to track
this.

I don't think we even need any other limit - this would limit the number of
function invocations to O(bitwidth) as after that many ORs we're guaranteed
to hit a bailout.

James
On Mon, 4 Jan 2016 at 19:48, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Mon, Jan 04, 2016 at 05:39:27PM +0000, James Molloy via llvm-commits
> wrote:
> > jmolloy created this revision.
> > jmolloy added a reviewer: joerg.
> > jmolloy added a subscriber: llvm-commits.
> > jmolloy set the repository for this revision to rL LLVM.
> >
> > It is possible to create an IR pattern that results in exponential
> execution
> > time in CollectBitParts, by making a tree where every OR refers to one
> other OR via *both*
> > operands:
> >
> >   for (i = 0; i < N; ++i)
> >       b |= b >> 1;  // Causes 2^N executions of CollectBitParts!
> >
> > To defend against this (and because ORs are the only node that cause us
> to
> > fork control flow) we keep a counter alive between all invocations of
> > CollectBitParts, expected to be initialized to bitwidth(b).
>
> Can we memoise the expression tree instead we have already processed
> instead / additionally? Some form of limit for CPU time / memory use
> would still be needed, but that would cut the problem down as well,
> wouldn't it?
>
> Joerg
> _______________________________________________
> 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/20160104/46d99930/attachment.html>