JIT: Type fat pointer locals precisely, and avoid unnecessary normalization in inlining

[jakobbotsch]

During call importation, for fat pointer calls we will introduce a local and spill the call to it. This loses track of the small typedness of the value, which can cause inlining to introduce unnecessary normalization casts later. For tailcalls this can cause us to add IR after the call that we do not expect, causing issues like #99798.

Fix the problem by enhancing logic in a few places:

• Make the local created for these fat pointer calls small typed like regular small normalize-on-store locals
• Enhance fgCastNeeded to take into account the small-typedness of these locals (like IntegralRange::ForNode)

Some regressions because we remove unnecessary casts which makes this early-out in forward sub kick in:

runtime/src/coreclr/jit/forwardsub.cpp

Lines 724 to 743 in b94364e

	// Finally, profitability checks.
	//
	// These conditions can be checked earlier in the final version to save some throughput.
	// Perhaps allowing for bypass with jit stress.
	//
	// If fwdSubNode is an address-exposed local, forwarding it may lose optimizations due
	// to GLOB_REF "poisoning" the tree. CQ analysis shows this to not be a problem with
	// structs.
	//
	if (fwdSubNode->OperIs(GT_LCL_VAR))
	{
	unsigned const fwdLclNum = fwdSubNode->AsLclVarCommon()->GetLclNum();
	LclVarDsc* const fwdVarDsc = lvaGetDesc(fwdLclNum);
	if (!varTypeIsStruct(fwdVarDsc) && fwdVarDsc->IsAddressExposed())
	{
	JITDUMP(" V%02u is address exposed\n", fwdLclNum);
	return false;
	}
	}

Fix #99798

[dotnet-policy-service]

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

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @EgorBo

Diffs

[EgorBo]

Do you know why the assert started failing recently?

[EgorBo]

why not fix it then?

[jakobbotsch]

I opened #99808 about fixing it. I mainly think we should separate the diffs + create a regression test for it.

[jakobbotsch]

Do you know why the assert started failing recently?

It's exposed by #99265. The callee is a shared generic in this case.

[EgorBo]

Do you know why the assert started failing recently?

It's exposed by #99265. The callee is a shared generic in this case.

Weird, I had many CI runs in my PR and didn't see it there, but it's possible of course

[jakobbotsch]

Weird, I had many CI runs in my PR and didn't see it there, but it's possible of course

It did fail in the runtime-nativeaot-outerloop run on that PR: https://dev.azure.com/dnceng-public/public/_build/results?buildId=596527&view=results (you can see the assert in the console log for "windows-x64 Checked NativeAOT_Pri0" there).