Add optimization to avoid copying a struct if passed by reference and there are no writes to and no reads after passed to a callee.

[LLITCHEV]

On Windows structs are allocated on the caller stack and passed by ref to the callee.

If a struct is passed to a callee (callee1), which passes it to another callee (calee2), and there are no writes before the call to callee2, and there are no reads after passing to the callee2, the callee1 could pass to calee2 the reference that was passed to it, without need to allocate a new struct on the callee1 stack and copy the data.

category:cq
theme:structs
skill-level:expert
cost:extra-large

[omariom]

Is it similar to https://github.com/dotnet/coreclr/issues/1133?

[LLITCHEV]

@omariom Yes... It is very similar. This optimization should result in better codegen for handful of cases not described in 1133, I think.

Thank you for pointing out the existing Issue and linking them together.

[CarolEidt]

This is really a distinct issue from #4308. In that issue, what's at issue is that:

• First, the inliner creates copies for all struct parameters, and
• Second, value numbering is not fully enabled for structs, so the copies do not get eliminated.

Addressing this issue requires a different kind of analysis, to determine that the struct being passed is not modified, and is not read after the call to callee1.

A repro, in particular one that reflects an actual real-world scenario, would be useful in prioritizing this.

[ghost]

This issue has been automatically marked no recent activity because it has been marked as needs more info but has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no recent activity.

Please refer to our contribution guidelines for tips on what information might be required.

[ghost]

This issue will now be closed since it had been marked no recent activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.