[PATCH] D15857: [InstCombine] Defend against worst-case exponential execution time
Joerg Sonnenberger via llvm-commits
llvm-commits at lists.llvm.org
Mon Jan 4 11:47:46 PST 2016
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
More information about the llvm-commits
mailing list