Increase ConstraintAnalysis limit on basic block computations

[kripken]

10 * MaxBinaryActions is far too low, as CFGs can be complex enough to
hit that. Use something far, far higher, unlikely to ever be seen in practice,
but enough to assert instead of hanging, in case we have a bug.

[tlively]

Should we move the tracking of the count behind the NDEBUG macro as well?

[kripken]

No, we do need to track the count. Stopping at 20 is what stops us from going 1,2,3 all the way into 1,000,000.

For loop increment reasons, our 20 limit is needed in production. In debug, we also check for 1,000,000 for hangs.

[tlively]

Oh, then I think I misunderstood our conversation earlier, then. I thought you were saying the shortcut we take for loop index variables was sufficient and that you didn't want to apply any further arbitrary limits. But I guess you meant we will keep the arbitrary limit of 20 iterations before widening to top and then have a "very large" debug-only limit for the number of times an expression can be visited?

[kripken]

Yes, sorry if I wasn't clear before.

1. Limit of 20 is needed to stop 1,2,3,... for loop vars
2. Higher limits will not affect loop vars - not unless we have a bug in loop vars - but can affect large CFGs
3. We should allow large CFGs
4. A debug-only check is added, large enough to never hit anything in practice (fingers crossed), but low enough to fire instead of a hang (if we have a loop var bug, or other)

[tlively]

Got it. Change LGTM, although I still think it would be cleaner (and more efficient!) to count the number of times new information flows to each basic block entry (or each variable at each basic block enty) rather than on every binary operation. As it is, you will have multiple binary expressions in the same basic block all incrementing their separate counters in the exact same way.

[kripken]

Yeah, I agree that might be better... still thinking about how to do it. The point of the counter is for Binary things, so I want that to be clear from the code.