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

[James Molloy via llvm-commits]

The number of ORs for a complete bitreverse is the same as the type
bitwidth.

If you want, we could inhibit this for large types?
On Mon, 4 Jan 2016 at 17:57, David Majnemer via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> majnemer added a subscriber: majnemer.
>
> ================
> Comment at: lib/Transforms/InstCombine/InstCombineAndOrXor.cpp:1775-1777
> @@ -1756,3 +1774,5 @@
>    SmallPtrSet<Value*, 2> OrValues;
> -  if (CollectBitParts(&I, 0, BitMask, BitValues, BitProvenance, OrValues))
> +  unsigned NumOrsRemaining = BitMask.getBitWidth();
> +  if (CollectBitParts(&I, 0, BitMask, BitValues, BitProvenance, OrValues,
> +                      NumOrsRemaining))
>      return nullptr;
> ----------------
> This seems a bit much if you have i128.  What is NumOrsRemaining typically
> when this optimization kicks in?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D15857
>
>
>
> _______________________________________________
> 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/0bd962c3/attachment-0001.html>