JIT: Account for mixed-enregistered locals when zeroing without block-init

[jakobbotsch]

Locals that are in registers at the beginning of a function do not need to have their stack home zeroed. genFnProlog already skips these locals when computing the range of bytes to zero; however, genZeroInitFrame was not doing the same in the non-block init case (which ignores the range computed by genFnProlog). This could cause an unbounded amount of (unnecessary) codegen during zero-initing, which is not legal to have in the prolog.

Fix #104570

[dotnet-policy-service]

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

[jakobbotsch]

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[tannergooding]

In genCheckUseBlockInit it looks like the main loop only increases initStkLclCnt when varDsc->lvIsOnFrame.

So couldn't we use that as an early out detection mechanism? Basically:

if (!varDsc->lvMustInit || !varDsc->lvOnFrame)
{
    continue;
}

There's then a secondary handler that increments for spill temps containing pointers, but that looks to be independent of this main loop in genZeroInitFrame and is handled in its own subsequent loop.

[jakobbotsch]

genCheckUseBlockInit will set lvMustInit, so I don't think we need more checks here... the logic is that if genCheckUseBlockInit left lvMustInit as 1 and it isn't in a register, then it must be on frame as otherwise we wouldn't need to init it.

[tannergooding]

LGTM. It's somewhat hard to correlate the logic done in genCheckUseBlockInit in contrast to the logic done in genZeroInitFrame, I think long term it'd be ideal if these could be more explicit between the two to make it very clear that we're handling the right things.

[jakobbotsch]

LGTM. It's somewhat hard to correlate the logic done in genCheckUseBlockInit in contrast to the logic done in genZeroInitFrame, I think long term it'd be ideal if these could be more explicit between the two to make it very clear that we're handling the right things.

Yeah... @AndyAyersMS has had musings about creating an actual object model of the stack frame, which would also make this stuff harder to get wrong.

[jakobbotsch]

cc @dotnet/jit-contrib

libraries-jitstress failures look like #104613, #104605, #102706, #104269/#103940/#103630/#103549, #104366
Other failures look like infra issues.