C++: Add another IR consistency query

[MathiasVP]

As discussed async, in the guards library we currently have special logic to handle the fact that C databases don’t have int-to-bool conversions in stuff like:

int x = ...
if(x) {
  ...
}

because of those missing conversions, the IR simply branches on the load of x instead of the result of a CompareNEInstruction. While this makes sense since some versions of C doesn't have a Boolean type. However, it does mean that we have to special-case this in the guards library (for example, the inNonZeroCase column in #16533).

I now realize, however, that it’s probably simpler to just add those CompareNEInstructions as part of IR generation. Then we don’t need that complexity in the guards library at all, and we don’t need to think about whether we’re in C or in C++ in the library.

The IR changes itself are pretty trivial, but in order to get a feeling for whether they work on real-world databases I'm first adding a new consistency check.

[dbartol]

LGTM.

Skimming over the results from the new consistency query, they seem to be all in C code, which is what we expected.

[jketema]

LGTM. Do the syntax-zoo test results also need to be updated?

[jketema]

I'm not sure to what extent you want to change the IR behavior here, but this probably requires some care with cases like the following (for which you have already added a test):

int y = ...;
int x = !y

[MathiasVP]

Yep, I intend to fix those cases as well 👍

[dbartol]

For !y, I'd suggest doing the same thing we do for C++, which is to first convert the int to bool via CompareNE.

Separate from the consistency issue, I wonder if translating !y directly as CompareEQ, instead of CompareNE, LogicalNot, would give better results somewhere.

[MathiasVP]

Separate from the consistency issue, I wonder if translating !y directly as CompareEQ, instead of CompareNE, LogicalNot, would give better results somewhere.

The problem with this is the translation back to Exprs (which we need in particular when someone does dataflow to a condition of an if statement). In that case, the unconverted result expression should be the CompareNE, and the converted result expression should be the LogicalNot. But if we merge them together as a CompareEQ then the unconverted result expression of !y would be a CompareEQ which is a bit strange.