inlining: avoid source deserialization by using volatile inference result

[aviatesk]

Currently the inlining algorithm is allowed to use inferred source of
const-prop'ed call that is always locally available (since const-prop'
result isn't cached globally). For non const-prop'ed and globally cached
calls, however, it undergoes a more expensive process, making a
round-trip through serialized inferred source.

We can improve efficiency by bypassing the serialization round-trip for
newly-inferred and globally-cached frames. As these frames are never
cached locally, they can be viewed as volatile. This means we can use
their source destructively while inline-expanding them.

The benchmark results show that this optimization achieves 2-4%
allocation reduction and about 5% speed up in the real-world-ish
compilation targets (allinference).

Note that it would be more efficient to propagate IRCode object
directly and skip inflation from CodeInfo to IRCode as experimented
in #47137, but currently the round-trip through
CodeInfo-representation is necessary because it often leads to better
CFG simplification while cfg_simplify! being expensive (xref: #51960).

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[vtjnash]

An interesting optimization additional here might be to also skip copying it the first time and instead delete it, so that only later uses of the same result make a copy (from the serialized cache), if present. If that makes sense?

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your job failed.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[aviatesk]

An interesting optimization additional here might be to also skip copying it the first time and instead delete it, so that only later uses of the same result make a copy (from the serialized cache), if present. If that makes sense?

It looks like your idea enhances the performance pretty much. Thanks!

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.