C++: Range analysis measure bounds

[paldepind]

This PR intends to address (some) performance issues in the simple range analysis library.

The basic idea is rather simpler:

1. Do a simple pre-analysis that tries to estimate how many bounds the range analysis would produce for a given expression. For instance, the number of bounds for e1 + e2 is number the number of bounds for e1 times the number of bounds for e2.
2. If the estimate is large for a given expression then we turn on widening for that expression. This ensures that when range analysis runs the estimated blowup does not happen.

Note to reviewers:

• Per commit review is probably easiest.
• I've tried to thoroughly document stuff in comments (which I wont repeat that here). The comment for nrOfBoundsExpr is a good place to start.
• A good chunk of code is quite straightforward. The tricky bits are around how phi nodes are handled. Things are a bit heuristic-y there, more optimal things might be possible, and there's a few details about the phi nodes here that I'm still a bit puzzled by. I've tried to add comments, but I think it's ok if a reviewer don't follow all the details there.
• The limit beyond which widening is turned on is very large. This is to be conservative. We could lower it later.

[Copilot]

Pull Request Overview

This PR addresses performance issues in the C++ simple range analysis library by implementing a pre-analysis to estimate bounds growth and applying widening when the estimate exceeds a threshold. The solution prevents combinatorial explosions that could cause analysis timeouts.

Key changes:

• Adds bounds estimation logic (BoundsEstimate module) that estimates potential bounds count before running full analysis
• Implements selective widening based on bounds estimates to prevent performance issues
• Updates test cases to reflect new analysis behavior with widening applied to expressions with many estimated bounds

Reviewed Changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
SimpleRangeAnalysis.qll	Core implementation adding bounds estimation module and widening logic
test.c	New test cases demonstrating combinatorial explosion scenarios
upperBound.expected	Updated expected results reflecting widening behavior
lowerBound.expected	Updated expected results reflecting widening behavior
ternaryUpper.expected	Updated expected results for ternary expressions
ternaryLower.expected	Updated expected results for ternary expressions
nrOfBounds.ql	New test query for bounds estimation debugging

Comments suppressed due to low confidence (1)

cpp/ql/lib/semmle/code/cpp/rangeanalysis/SimpleRangeAnalysis.qll:1

• Corrected spelling of 'anncuracies' to 'inaccuracies'.

/**

[geoffw0]

Strategy seems sensible to me (but @MathiasVP has spent much more time working with this library). I will review the (second) DCA run when it finishes.

[paldepind]

Thanks for the review @geoffw0 with some great catches 👍. I've applied your suggestions.

[MathiasVP]

A few minor comments. Thanks a lot for this, Simon!

I think it would be good to add an inline expectations test which shows the number of bounds for a given expression. This would also make it easier to spot problems with non-functionality of nrOfBoundsExpr. Would you mind adding such an inline expectations test while you're here?

[MathiasVP]

I think this is a perfectly fine threshold to start with. FWIW when I introduce an "arbitrary threshold" like this I like to do a small amount of investigation into the underlying distribution. See for example what I did in this PR from last year where I plotted "number of nested bitwise operations" for each bitwise operation in a database. It would be interesting to see a similar plot for "number of bounds" for each expression on a database or two.

... but as I said: I think this very high arbitrary threshold is perfectly fine as a start.

[paldepind]

That's a good point. @andersfugmann also suggested that we could create a statistics query and potentially get telemetry for this to make a more quantified upper bound.

[MathiasVP]

This likely doesn't give us the best possible join ordering since this recursion is non-linear, but we've never bothered to actually fix this in the main recursion of SimpleRangeAnalysis itself so it's probably all fine.

[paldepind]

I've kicked off another DCA run for good measure, but assuming that one doesn't show anything then I think we're good to merge?

There is the option of doing a QA run as well. But the change seems low enough of a risk that that's worth it? Thoughts?

[paldepind]

There's some failures in DCA now and retrying didn't make them go away. Looking at the errors, they don't really look like they're caused by the QL changes.

[jketema]

There's some failures in DCA now and retrying didn't make them go away. Looking at the errors, they don't really look like they're caused by the QL changes.

Those errors were fixed late yesterday afternoon. Could you re-run?

[paldepind]

Thanks @jketema. I triggered retries 2 hours ago, should I start a new DCA run or just do the retry commands again?

[jketema]

I don't think retries work in this case: you'll need to start a new experiment.

[paldepind]

I think this is ready to merge now. Please double-check that y'all agree with my assessment of the DCA report.

[geoffw0]

DCA LGTM.

@MathiasVP were all your questions addressed?

[MathiasVP]

@MathiasVP were all your questions addressed?

The only thing I am missing is this part of my review:

I think it would be good to add an inline expectations test which shows the number of bounds for a given expression. This would also make it easier to spot problems with non-functionality of nrOfBoundsExpr. Would you mind adding such an inline expectations test while you're here?

[paldepind]

I agree that inline expectations would be nice (perhaps even more so for the lower/upper bounds themselves). But, is it ok if we don't do that for now?

[geoffw0]

The additional test can be done as follow-up.