[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