Enable escape analysis and use in vn

[AndyAyersMS]

Note this does not enable stack allocation of ref classes—the aim is to let downstream phases treat the memory from non-escaping objects more aggressively, since it's not exposed cross-thread.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[AndyAyersMS]

FYI @EgorBo @jakobbotsch @SingleAccretion

This allows a limited amount of propagation for fields of non-escaping heap objects.

I would like VN to know that the backing storage for non-escaping heap object fields is all zero -- any suggestions on the best way to implement that?

Also I am tempted to say that non-escaping news have no effect on the global heap state... still thinking about that one.

Finally I'd like to enable dead store for fields of nonescaping heap objects (with the hope that perhaps we eventually can remove all reads and writes, and then somehow realize the allocation itself is dead, and remove that too).

VN based dead store only considers local defs, and it's not structured in a way that generalizes to field defs. I was going to tack the heap based version on here anyways, and only run it if (a) we have nonescaping news; (b) something (perhaps VN) detects that there are heap stores that are not needed.

In a related set of changes, I have support for adding field seqs to boxes, which would light up all of the above for boxes too... I haven't tried running the two together yet.

[jakobbotsch]

Is the main benefit here expected to come from boxes? How much work do you think it would be to enable the more general object stack allocation for boxes and have this fall out from physical promotion instead?

I would like VN to know that the backing storage for non-escaping heap object fields is all zero -- any suggestions on the best way to implement that?

This sounds similar to #96942. When I looked at it I didn't immediately see how to represent this in VN, since memory is handled on a field-by-field basis.

[AndyAyersMS]

Test failure is the object allocation test, we now stack allocate in one more case (because of non-escaping helper info).

I would like VN to know that the backing storage for non-escaping heap object fields is all zero -- any suggestions on the best way to implement that?

This sounds similar to #96942. When I looked at it I didn't immediately see how to represent this in VN, since memory is handled on a field-by-field basis.

We know the class, so we could enumerate the fields and add zero stores to each field, but that seems a bit clunky.

[AndyAyersMS]

Stats on asp.net are pretty dire -- for optimized methods

57554 allocation sites
   87 non-escaping

And just one method with a diff.

[hez2010]

The current analysis is pretty limited, it even won't account for cases like:

var b = new B(42);
var a = new A(b); // the current analysis considers b being escaped
Console.WriteLine(a.Inner.V);

record A(B Inner);
record B(int V);

[AndyAyersMS]

The current analysis is pretty limited,

It is, but there is also some healthy skepticism that it's fundamentally never going to be very good. However, I am surprised there are so few non-escaping allocations. I would at least expect to see a more sizeable number of non-escaping boxes in generic code. So we'll need to dig in somehow and see what's up.

[AndyAyersMS]

Escape analysis has indeed gotten a bit stale, with some small fixes the number of non-escaping news increased from 87 to 153. If I break it down by ref class / value class, I lose a lot of SPMI contexts (since we seemingly don't ask for the class attribs all that often), but of the contexts that survive, I see

15172 ref class news
    9 don't escape
 2012 value class news
   27 don't escape

So perhaps a bit more encouraging: if we can show 1% of boxes don't escape... including the one from #9118, perhaps it is worth pushing further.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.