C++: Field flow through reference-returning functions #11374

MathiasVP · 2022-11-22T14:13:14Z

This PR adds use-use flow through examples such as:

int source();
void sink(int);

struct MyInt {
  int i;
  int* get() { return &i; }
};

void test()
{
  MyInt mi;
  *mi.get() = source();
  sink(mi.i);
}

It turns out we almost had this flow on the feature branch already. The shared dataflow library has a concept of flow-through here. This disjunct is responsible for adding a store step from c [post update] to getB() [post update] in the following example:

struct B { int c; };
struct A {
  B b;
  B* getB() { return b; }
};
...
a.getB()->c = v;

the rule used by the shared dataflow library is as follows:

Generate a store step from node1 to node2 (storing f) if:

node1 is a PostUpdateNode with a pre-update node that is an output of a function (that's getB() [post update] in our example above node above with a pre-update node of getB())
node2 is a PostUpdateNode with a pre-update node that is an argument to a function (that's a [post update] in our example above with a pre-update node of a).
There's flow from the argument node, into the function, and to a read step that reads f, which then flows to a return node of the function.

Step 2 and 3 already worked for our example, but there was no PostUpdateNode with a pre-update note that was the output of the function. So this PR simply marks the appropriate OutNode as a PostUpdateNode and assigns the pre-update node to this.

Having the pre-update node equal the post-update node is a consistency violation (as demonstrated by the tests). I'm not aware of anything bad happening due to this, however. I'll run DCA to make sure, though 🤞.

MathiasVP · 2022-11-22T16:56:35Z

DCA looks good 🎉. No result changes, and no performance changes.

rdmarsh2 · 2022-11-22T21:47:39Z

marks the appropriate OutNode as a PostUpdateNode and assigns the pre-update node to this.

What do other languages do here? Separate post-update and pre-update nodes for each return?

aschackmull · 2022-11-23T08:33:55Z

I'm not aware of anything bad happening due to this, however

The thing that can happen is weird FP flow in certain cases. If the store step that targets the result of the wrapped read isn't written directly, as it is in your examples, but instead occurs as a side-effect of a call then you'll get spurious re-entry flow into that setter. Let me demonstrate with an example:

Foo getFoo() { return this.foo; }
...
void setBar(x) {
  sink(this.Bar);
  this.Bar = x;
}
...
x.getFoo().setBar(source())

If the OutNode associated with the result of getFoo is its own PostUpdateNode then the post-update will also be an argument to setBar and the result of the side-effect from setBar will then be able to re-enter setBar and cause FP flow from source to sink.

MathiasVP · 2022-11-23T09:43:24Z

Thanks for your input, @aschackmull! Luckily, the above example doesn't apply in this case since we're doing the Right Thing℄1�7 for constructs such as:

x.getFoo().setBar(source())

where x.getFoo() will have a post-update node x.getFoo() [post update] since it's the argument of a function call (and its pre-update node will be the expression node for x.getFoo()).

This PR only does the pre-update = post-update on constructs like *mi.get() = source(); (where the destination address is an address returned by a call to a function that returns a reference or a pointer).

C++: Better support for flow-through.

6233722

MathiasVP requested a review from a team as a code owner Nov 22, 2022

github-actions bot added the C++ label Nov 22, 2022

MathiasVP added the no-change-note-required This PR does not need a change note label Nov 22, 2022

C++: Field flow through reference-returning functions #11374

C++: Field flow through reference-returning functions #11374

MathiasVP commented Nov 22, 2022

MathiasVP commented Nov 22, 2022

rdmarsh2 commented Nov 22, 2022

aschackmull commented Nov 23, 2022

MathiasVP commented Nov 23, 2022 •

edited

C++: Field flow through reference-returning functions #11374

Are you sure you want to change the base?

C++: Field flow through reference-returning functions #11374

Conversation

MathiasVP commented Nov 22, 2022

MathiasVP commented Nov 22, 2022

rdmarsh2 commented Nov 22, 2022

aschackmull commented Nov 23, 2022

MathiasVP commented Nov 23, 2022 • edited

MathiasVP commented Nov 23, 2022 •

edited