[MIR] Reconsider invoked function return value strategy

[nagisa]

Currently in MIR function calls look like this:

destination = function(...) -> [...]

where destination is a lvalue of some sort. However this assignment is a little bit troublesome where under-the-covers we need to copy the return value and zero-fill the arguments after the call finishes.

LLVM has two kind of cals invoke and call. call is a regular instruction, whereas invoke is a basic block terminator. There’s no problem with the call instruction, because we can always produce a bunch of post-call code after call and then simply br into the destination block. invoke, however, does not give us that kind of freedom and we must branch into something right after the call. (remember, we still must to copy the return value and zero-fill the arguments!).

Previously we used to generate an intermediate block and translate the copy into that, but it is problematic and gets even more-so with zeroing considered. Lately we’ve moved to translating drops/copies straight into the target block (the at_start approach) – it turns out this is wrong in its current form, because the target block can easily have more than one predecessor!

The options considered and not considered are:

• Pre-trans pass to add empty blocks for all invokes like that and just use at_start approach;

  1. this is pretty clean in a sense that it is fully contained within trans and we get to see whole mirmap so we can do the transformation (something that’s not possible generating blocks during trans);
  2. lets us keep the at_start approach which is the cleanest one I’ve thought up so far; but
  3. generating blocks correctly would be not-really-trivial.

• @nikomatsakis had proposed having function return value as an rvalue which must appear inside the first statement in target block. I.e. something like

  bb1: function(...) -> [bb2]
  bb2: destination = funcret
  

  This seems pretty clean, and we could also zero-out arguments as a part of funcret, but there’s a few issues with this approach that come to mind:

  1. funcret cannot be removed as part of optimisations (special case in optimisation passes);
  2. we’d have to somehow carry the state around trans?

That’s all my thoughts so far. This is pretty important to get fixed, because it causes llvm assertions for some code.

[nagisa]

Just for the record, I would not like to return to the long comment approach, because alongside fictional phis it now also has to consider cleanuppad which we use extensively.

[eddyb]

Just for the record, I would not like to return to the long comment approach, because alongside fictional phis it now also has to consider cleanuppad which we use extensively.

Just for the record, I had to, during (yet unpushed) MIR work for #32080, just so I can get libcore to generate unbroken LLVM IR.

[Aatch]

Your description of the issue with the current at_start seems very similar to critical edges. Critical edges are edges in a CFG that are neither the only edge leaving a block, nor the only edge entering a block.

    bb0
    / \
   /   \
  /     \
bb1    bb2
 |     / \
 |    c   \
 |   /     \
 bb3      bb4

So edge c here is a critical edge as it's not the only edge leaving bb2 and it's not the edge ending bb3. The thing with critical edges is that you have to break them (by inserting new blocks) to add computation along them without affecting the other edges, which seems pretty similar to the issue here.

Identifying and breaking critical edges is a known problem, so it shouldn't be too hard to find algorithms for doing both. I don't know enough about what is going on here to know the best overall strategy though.

[nagisa]

@Aatch thanks for the input. I’ve thought about your graph more and came to conclusion that we may potentially have trouble in a more general case of target block having more than a single predecessor.

Namely something like

bb0(Drop -> bb2)     bb1(Drop -> bb2)
      \                     /
        \                 /
             bb2(...)

Is enough to make at_start go wrong, regardless of how many successors bb0 and bb1 actually have.

[arielb1]

@nagisa

I think that forcing the target of an invoke to be a basic block to have a single source (either in MIR construction or in a post-processing pass) would be the best option. This is a simple invariant, and funcret would break RVO.

Why would you use at_start with single-successor Drop?

[arielb1]

cleanuppad will stop being a problem when we get non-zeroing drop - we can mark the arguments as dropped before the call - it's not like we have any asynchronous exceptions to be afraid of. Then we only have to copy the destination and set its drop-flag if needed.

[nikomatsakis]

OK, I see a variety of options here, most of which @nagisa summarized. These options are all basically the same, but they build on one another in some sense. The key point is that the edge that leads out of an invoke is special. But in each case we are moving this "specialness" further back:

1. Handle this in MIR trans by making a basic block for invoke edges. The transformation to basic blocks is then actually fairly simple: there is an LLVM basic block for every MIR block AND every MIR edge. However, we optimize out the edge blocks the vast majority of time; we only include them for those cases where we with to insert code on the edge (which is where we NOW call at_start). Here the specialness of the edge is specific to trans.
2. Same as Option 1, but do this "edge-splitting" transformation in the MIR before we enter trans. Here the specialness of the edge is specific to "LIR" (that conceptual variant of MIR where we have performed various optimizations post type-checking).
3. Same as Option 2, but insert an extra block for edges that we may need to split, and make sure we never strip this block during optimizations and so forth, even if it is empty. Here the specialness of that edge is an invariant we maintain on MIR.
4. Modify Call and have a special rvalue. Here the specialness of the edge is recognized by the structure of the MIR itself. This is essentially the same as Option 3, really, except that we would never strip the "edge block" as empty because it would never be empty, it would have the special rvalue assignment.

My opinion is roughly that we should go for either 1 or 4. The others feel like silly compromises. The reason to go for Option 4 is basically that trans is not the only piece of code that cares about this edge being a bit special -- dataflow needs to understand that too, since the initialization of the target occurs only if there is no unwinding. So if we adopt Option 4, then this fact is embedded in the MIR, and both trans/dataflow profit. Otherwise, though, it is something they both have to hardcode. That said, the hardcoding may in fact be very simple to achieve, so maybe that's fine!

[nikomatsakis]

@arielb1

This is a simple invariant, and funcret would break RVO.

Can you elaborate on this? I do not believe that funcret would break RVO. In particular, every invoke instruction would have (as an invariant) a successor which begins with funcret. Therefore, we can easily find the destination by peeking at the first instruction of our successor block, so there should be no problem in passing this pointer into the function we are calling.

[arielb1]

LIR

If we want to represent non-zeroing drop in the MIR, we would need to add MIR "design rules" (at least, explicit/implicit MIR drop flags).

We can easily insert the guard blocks late in the pipeline - that's option 2.

In particular, every invoke instruction would have (as an invariant) a successor which begins with funcret.

That sounds like a non-trivial and hard-to-fix-up invariant. Also, funcret would have a potentially different type on every use, and more implicit annoyances.

[nikomatsakis]

@arielb1

If we want to represent non-zeroing drop in the MIR, we would need to add MIR "design rules" (at least, explicit/implicit MIR drop flags).

My plan was to add explicit DROP flags -- literally boolean temporaries, and then extend DROP to take a "condition" flag (always True at first). Or else make a ConditionalDrop terminator.

This comes back to the general vision of having a conceptual "LIR" which is represented using the same MIR data structures. This LIR would be produced by borrowck (which removes the "zeroing drop" semantics) and then modified by whatever optimizations we choose to do after that.

That sounds like a non-trivial and hard-to-fix-up invariant.

It seems no more or less hard to maintain than "invoke must have a block with a single predecessor". But I'm pretty indifferent really. I think I even lean against the funcret rvalue at this point, until there is more evidence of pain with the current setup. In that case, I lean towards "add a special basic block representing this edge in trans" -- minimally invasive to the rest of MIR.

Also, funcret would have a potentially different type on every use, and more implicit annoyances.

I don't really see why this would be annoying either. Presumably it would be funcret<T> where T is the type of value being returned (or type of function being called).

I guess the bottom line is that funcret still seems harmless to me, but probably not useful enough to go through the trouble of adding.

[nikomatsakis]

It seems no more or less hard to maintain than "invoke must have a block with a single predecessor". But I'm pretty indifferent really. I think I even lean against the funcret rvalue at this point, until there is more evidence of pain with the current setup. In that case, I lean towards "add a special basic block representing this edge in trans" -- minimally invasive to the rest of MIR.

Actually, reading through pnkfelix's recent PR, I'm mildly revising this opinion. Basically: dataflow either wants a successor with one predecessor OR to associate gen/kill sets with the edges themselves. Perhaps the latter is cleanly achievable though.

[arielb1]

@nikomatsakis

I thought to use regular if conditionals to handle non-zeroing-drop, along with added temporaries. I am calling this a "design rule" is because the MIR produced by adding the drop flags is still valid MIR (adding another set of drop flags, either on-stack or inline, would be harmless).

It seems no more or less hard to maintain than "invoke must have a block with a single predecessor".

We don't need to maintain it through passes. We can just establish it whenever we want, and the MIR stays valid. OTOH, the funcret is an integral part of MIR and must be maintained through all passes.

[nagisa]

A problem with funcret that we would end up copying things we return via outpointer. Optimised code probably does not care, but copying data returned via outpointer is potentially many times more expensive than copying of primitive values we do currently in the no-optimisations mode.

(OTOH, we already copy everything around a bunch of times in non-optimized mode regardless, do that probably is not as critical as it sounds)

[arielb1]

I think @nikomatsakis's proposal was to treat = funcret as a phi.