I don't think any other language exposes SSA in terms of data flow nodes. I can see the motivation, though, it's a much shorter path to impact than, say, getting a good SSA on the AST nodes. But it's important to highlight that this is not really pointing in the direction of language api unification (the glorious future).
I don't like the name DataFlow::Definition - I think Ssa should be in there somewhere in the name: Either DataFlow::Ssa::Definition or DataFlow::SsaDefinition (same of course goes for the other class names).

I'm happy to rename it to SsaDefinition. As far as I can tell C# calls them Definitions and Java calls them SsaVariables. So using Definition was my way of actually trying to be consistent with at least one other language 😅

Using DataFlow::Nodes for the API makes it a lot easier to work with in C/C++ since the alternative would be to define them in terms of (Expr, int) pairs (or (Instruction/Operand, int) pairs) to allow correctly handling indirections. By using DataFlow::Nodes which are already defined basically as (Instruction/Operand, int) pairs we get a much cleaner API from the C/C++ point of view, at least.

But I can see the value in trying to align with other languages on this. I'll experiment a bit and see if I can find a balance that I like 🤔

Bahh! We can't even name it SsaDefinition because of this stupid old library that we only use in SimpleRangeAnalysis 🤯 So I'll do DataFlow::Ssa::Definition instead, and then we can always move it (with a long deprecation cycle) once we get rid of SimpleRangeAnalysis

But I can see the value in trying to align with other languages on this. I'll experiment a bit and see if I can find a balance that I like

Ultimately, I think a canonical SSA for C++ could be based on a new class that encapsulates the (Expr, int) pair. Ideally this would provide the same benefits as the data flow SSA, but without a strong tie to the data flow nodes (because there may well be use-cases for SSA on which we'd like data flow nodes to depend - or at least leave us that option). In general I think it makes sense to have a SourceVariable class (that's what it's called in the SSA input sig) that covers more than just surface-level local variables. Java (and C#) e.g. includes (qualified) fields, such that x.y.z gets SSA with suitable updates when x or x.y changes. Putting pointer variables plus their indirections into that setting makes sense, I think. In general, for a given language, I think these SSA source variables should cover whatever surface level constructs that are likely to repeatedly occur in a function, and where programmers expect the value to be unchanged in most cases for repeated occurrences - we should perhaps draw a little inspiration from whatever experience we have from value numbering (as that's in some ways the ad-hoc approximation). For instance, C# likely wants to include property accesses.

As far as I can tell C# calls them Definitions

C# generally refers to them as Ssa::Definition. Unqualified use of the Definition name is restricted to within the SSA libraries.

C# generally refers to them as Ssa::Definition. Unqualified use of the Definition name is restricted to within the SSA libraries.

Ah, right. I'll follow that direction, then.

Ultimately, I think a canonical SSA for C++ could be based on a new class that encapsulates the (Expr, int) pair. Ideally this would provide the same benefits as the data flow SSA, but without a strong tie to the data flow nodes (because there may well be use-cases for SSA on which we'd like data flow nodes to depend - or at least leave us that option). In general I think it makes sense to have a SourceVariable class (that's what it's called in the SSA input sig) that covers more than just surface-level local variables. Java (and C#) e.g. includes (qualified) fields, such that x.y.z gets SSA with suitable updates when x or x.y changes. Putting pointer variables plus their indirections into that setting makes sense, I think. In general, for a given language, I think these SSA source variables should cover whatever surface level constructs that are likely to repeatedly occur in a function, and where programmers expect the value to be unchanged in most cases for repeated occurrences - we should perhaps draw a little inspiration from whatever experience we have from value numbering (as that's in some ways the ad-hoc approximation). For instance, C# likely wants to include property accesses.

Indeed, that makes a lot of sense! I'll keep the API minimal for now and leave open the option of providing an (Expr, int) pair in the future.

g> I don't think any other language exposes SSA in terms of data flow nodes. I can see the motivation, though, it's a much shorter path to impact than, say, getting a good SSA on the AST nodes. But it's important to highlight that this is not really pointing in the direction of language api unification (the glorious future). I don't like the name DataFlow::Definition - I think Ssa should be in there somewhere in the name: Either DataFlow::Ssa::Definition or DataFlow::SsaDefinition (same of course goes for the other class names).

I've renamed the classes in 33d0598, and modified the API to not expose dataflow nodes (but rather Instructions and Operands) in b70836e.

I do agree that we ultimately would like a new abstraction around (Expr, int) pairs, but I'll leave that for the future.

I did a drive-by cleanups in 7ede3aa and 32e6d09. Nothing exciting is happening there (it's just renaming a few files and changing the name of some private import aliases).