JIT: Regularize readbacks for parameters/OSR-locals in physical promotion #87165
Conversation
…tion Handle readbacks for parameters/OSR-locals like any other readback is handled. Previously they were handled by creating the scratch BB and then inserting IR after the main replacement had already been done; now, we instead create the scratch BB eagerly and mark these as requiring a read back at the beginning of the scratch BB, and leave normal replacement logic up to handle it. The main benefit is that this unification makes it easier to ensure that future smarter handling of readbacks/writebacks (e.g. "resolution") automatically kicks in for the common case of parameters. Introduce another invariant, which is that we only ever mark a field as requiring readback if it is live. Previously we would always mark them as requiring read backs, but would then check liveness before inserting the actual IR to do the read back. But we don't always have the liveness information at the point where we insert IR for readbacks after dotnet#86706. Also expand some debug logging, and address some feedback from dotnet#86706.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsHandle readbacks for parameters/OSR-locals like any other readback is The main benefit is that this unification makes it easier to ensure that Introduce another invariant, which is that we only ever mark a field as Also expand some debug logging, and address some feedback from #86706.
|
jakobbotsch
force-pushed
the
lazy-readbacks
branch
from
de2e924
to
5ccea5c
Compare
jakobbotsch
force-pushed
the
lazy-readbacks
branch
from
5ccea5c
to
b001c60
Compare
|
Small number of diffs expected. They appear when there is an existing scratch block with some IR (typically a cctor invocation) and we now insert readbacks after that IR instead of before. That leads to some different register allocation. |
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-jit-experimental |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
jitstress restore failed with #84995... will restart it. |
|
/azp run runtime-coreclr jitstress |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-coreclr jitstress |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
cc @dotnet/jit-contrib PTAL @AndyAyersMS. Few diffs as mentioned above. Diffs with physical promotion, diffs without old promotion. I was mainly worried about TP of having another basic block to compute liveness for in these cases, but that doesn't seem to be costly. |
| // Retbuf -- these are definitions but we do not know of how much. | ||
| // We never mark them as dead and we never treat them as killing anything. | ||
| assert(isDef); | ||
| // We never treat them as killing anything, but we do store liveness information for them. | ||
| BitVecTraits aggTraits(1 + (unsigned)agg->Replacements.size(), m_compiler); | ||
| BitVec aggDeaths(BitVecOps::MakeEmpty(&aggTraits)); | ||
| // Copy preexisting liveness information. | ||
| for (size_t i = 0; i <= agg->Replacements.size(); i++) | ||
| { | ||
| unsigned varIndex = baseIndex + (unsigned)i; | ||
| if (!BitVecOps::IsMember(m_bvTraits, life, varIndex)) | ||
| { | ||
| BitVecOps::AddElemD(&aggTraits, aggDeaths, (unsigned)i); | ||
| } | ||
| } | ||
| m_aggDeaths.Set(lcl, aggDeaths); |
There was a problem hiding this comment.
We need this liveness here now to know what fields we need to mark for readback when a physically promoted struct is passed as the retbuf.
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-jit-experimental |
|
Azure Pipelines successfully started running 3 pipeline(s). |
Handle readbacks for parameters/OSR-locals like any other readback is
handled. Previously they were handled by creating the scratch BB and
then inserting IR after the main replacement had already been done; now,
we instead create the scratch BB eagerly and mark these as requiring a
read back at the beginning of the scratch BB, and leave normal
replacement logic up to handle it.
The main benefit is that this unification makes it easier to ensure that
future smarter handling of readbacks/writebacks (e.g. "resolution")
automatically kicks in for the common case of parameters.
Introduce another invariant, which is that we only ever mark a field as
requiring readback if it is live. Previously we would always mark them
as requiring readbacks, but would then check liveness before inserting
the actual IR to do the readback. But we don't always have the liveness
information at the point where we insert IR for readbacks after #86706.
Also expand some debug logging, and address some feedback from #86706.