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

James Molloy via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 5 03:17:30 PST 2016


Hi Joerg,

Actually on further investigation the simple solution of only visiting each
OR once isn't going to work.

There's an "OR of ORs" byte-swap idiom that relies on having the same OR in
both operands of another OR, the same pattern we're trying to defend
against. See http://reviews.llvm.org/rL248482 .

So the only defence I can think of is what I've already implemented, or to
memoize the tree as you suggested.

However, memoization seems to go against the spirit of instcombine - there
are no other similar caches kept that I can see, and any member of the tree
could be modified or optimized by instcombine in any iteration, so we'd
have to trawl the tree on every iteration to see if it has changed.

James

On Mon, 4 Jan 2016 at 21:36 James Molloy <james at jamesmolloy.co.uk> wrote:

> Yes, you're right, sorry.
> On Mon, 4 Jan 2016 at 21:20, Joerg Sonnenberger via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> > 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.
>>
>> I thought it is O(bitwidth * funsize)? Where funsize is the number of
>> expressions in the functions? That can be pretty large, but it isn't
>> needed, the limit would certainly be optional.
>>
>> 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/20160105/81845c7e/attachment.html>


More information about the llvm-commits mailing list