[llvm] r290755 - [NewGVN] Remove unneeded newline from assertion message.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 31 21:24:15 PST 2016


On Fri, Dec 30, 2016 at 8:09 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> It was chosen by taking a number of very large codebases, finding the max
> number, etc.
>
> 1. I just use it for finding infinite loops and bugpointing them, so we
> should remove it at some point.
> 2. The number is basically "what is the max number of loop connectedness
> of a program we will ever see".
> For most normal programs, it's like "2".
> For generated code, you can get to like 10.
> It would be an impressive mess of code to get more than that.
>
> We could make it 1000 for now if we want.
>
> We could also directly compute the loop connectedness and assert if we go
> more than that, but it's mostly a waste of time :)
>

This is fine if it is just for debugging / bringup.

>From your description though, it sounds like this is in fact not
technically an `assert`. I.e. it is possible to construct an input to (say)
`opt` with enough loop-connectedness to hit this assertion, and hitting the
assertion in that case would not be due to a bug.

It would be good to have a comment explaining this a bit better, ideally
mentioning the use right now only for debugging, the connection with
loop-connectedness, and the assumptions we're making about the
loop-connectedness of the inputs.

-- Sean Silva


>
>
>
>
>
> On Fri, Dec 30, 2016, 6:51 PM Davide Italiano <davide at freebsd.org> wrote:
>
>> On Fri, Dec 30, 2016 at 3:55 PM, Sean Silva <chisophugis at gmail.com>
>> wrote:
>> > Why 100? It seems weird to have an `assert` against a magic number like
>> > this; presumably the assert would fail if the magic number were 2 or
>> > something? What makes 100 "impossible"? It would be good to have this
>> in a
>> > comment.
>> >
>>
>> I think the number "100" is chosen kinda arbitrarily. Ideally we
>> shouldn't process every instruction more than an handful of times so
>> having an instruction processed 100 times is  likely an indication for
>> bugs. I agree it could be explained in a comment (happy to change),
>> but I'd like Danny to comment further if 100 was chosen for a
>> particular reason.
>>
>> Thanks!
>>
>> --
>> Davide
>>
>> "There are no solved problems; there are only problems that are more
>> or less solved" -- Henri Poincare
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161231/7290b2e2/attachment.html>


More information about the llvm-commits mailing list