C++: Fix __finally related inconsistencies

[jketema]

Note that although this fixes some inconsistencies this does not (yet) accurately reflect the semantics of __finally blocks. See the highlighted paragraph here.

Both DCA experiments are relevant. DCA shows a 10%~11% slowdown on keepassxc. It' not clear to me where this is coming from. I locally tried rerunning and I do see a small slowdown locally too (< 10%, but I was running single threaded), and the largest joins are identical between the two versions. So, I'm not sure what to do with this.

[MathiasVP]

The code changes LGTM! I'm surprised there are no reported IR inconsistency fixes in DCA, but I suppose we simply don't have any projects that use __try/__finally 😭

(I think this is a great PR to review in case someone wants to learn more about IR construction.)

[geoffw0]

Less inconsistencies is great. 🎉

I have nothing to add about the QL.

As for the slowdown in keepassxc, my best guess is that we're producing a chunk more data somewhere and the extra compute is being spread out among many predicates, so you're not seeing a spike. I've had no luck narrowing down what that extra data could be (my theory was less unreachable code).

[geoffw0]

I'm not seeing any slowdown locally, running queries like cpp/double-free that were highlighted in the Stage Timings report. How did you reproduce it locally? How confident are you that it's a real slowdown?

[jketema]

I'm not seeing any slowdown locally, running queries like cpp/double-free that were highlighted in the Stage Timings report. How did you reproduce it locally? How confident are you that it's a real slowdown?

I ran the whole nightly suite. The few reruns I did seemed to consistently show:

• Before:

  [2024-09-11 15:09:45] Total evaluation times for this run:
          * Wall-clock duration of evaluation run: 488.8 seconds
          * Total time spent evaluating predicates: 345.5 seconds
  

• After:

  [2024-09-11 14:55:09] Total evaluation times for this run:
          * Wall-clock duration of evaluation run: 495.2 seconds
          * Total time spent evaluating predicates: 345.5 seconds
  

So, much less then 10% looking at the wall-clock time. Curiously the predicate evaluation time is identical here.

[jketema]

@geoffw0 Maybe I'm a bit too paranoid here? If so, I'd like to go ahead and merge this 😅

[geoffw0]

I've nothing against merging this.

Might be worth checking the next nightly DCA though, and bring this up if a similar regression is observed.

[jketema]

Might be worth checking the next nightly DCA though, and bring this up if a similar regression is observed.

Will do!

[jketema]

I've nothing against merging this.

Thanks for your input!