C++: Range analysis on EquivalenceClasses

[MathiasVP]

Consider this snippet:

void notequal_refinement(short n) {
  if (n < 0) {
    range(n);
    return;
  }
  ...
}

the n in n < 0 has an implicit short-to-int conversion which means that the left-hand side of < is not actually a LoadInstruction of n, but instead a ConvertInstruction of the result of a LoadInstruction.

We could fix up all of these by doing a transitive closure from the LoadInstruction, through all "safe conversions" and figure out if we reached the operand of <. This is a bit ugly though, and we'd have to do this in multiple places.

Instead, this PR uses the new-ish QlBuiltins::EquivalenceRelation feature to define a new type that unifies unconverted instructions with their safe conversions. This means that the n in n < 0 really is the LoadInstruction (because the LoadInstruction and the ConvertInstruction is mapped to the same Expr).

[MathiasVP]

CI failure is unrelated (It's complaining about autoformatting in a couple of Java queries).

[MathiasVP]

Looks like this is crashing the QL compiler 😭. It only crashes the compiler with assertions enabled, however. So I was still able to run DCA (which looks fantastic now 🎉).

[rdmarsh2]

Minor style point, but I don't see why this can't just be

        tFrom = getSemanticType(this.getUnary().getResultIRType()) and
        tTo = getSemanticType(this.getResultIRType())

[MathiasVP]

Good call! Fixed in 4602a8a.

[rdmarsh2]

Can there be a situation where a Conversion or CopyValue appears in a different block than its operand?

[MathiasVP]

I've never encountered such a case, no.

[MathiasVP]

Actually, this query:

from ConvertInstruction instr
where instr.getUnary().getBlock() != instr.getBlock()
select instr

did produce up about ~30 results on Wireshark (all related to the ternary operator). I've added d9b2a72 to ensure that we only collapse instructions in the same block.

That was a good catch!