Check that we don't create null checks on an address that is not null.

[sandreenko]

@EgorBo in his previous Pr gave me an idea that it could be useful to check that we don't create a null check on an address that is known to be not null.

	crossgen	pmi
x64 windows	0	-15
arm64 windows	136	13
x64 linux	-59	-32

The biggest number of diffs involves methods on arm64 windows:

Top file regressions (bytes):
136 : System.Private.CoreLib.dasm (0.00% of base)
1 total files with Code Size differences (0 improved, 1 regressed), 267 unchanged.
Top method regressions (bytes):
28 ( 1.40% of base) : System.Private.CoreLib.dasm - GenericEqualityComparer`1:IndexOf(ref,ValueTuple`8,int,int):int:this (7 methods)
28 ( 1.38% of base) : System.Private.CoreLib.dasm - GenericEqualityComparer`1:LastIndexOf(ref,ValueTuple`8,int,int):int:this (7 methods)
16 total methods with Code Size differences (0 improved, 16 regressed), 195786 unchanged.

they all are in IndexOf or LastindexOf and are due to a new loop hoisting that is a size regression but a performance improvement.

[sandreenko]

It is questionable if it should be an assert or

if (!fgAddrCouldBeNull(addr))
{
// No need for a null-check.
return addr;
}

or something else.

[EgorBo]

it'd be weird for gtNewNullCheck to return something other than null-check 🙂

[sandreenko]

PTAL @AndyAyersMS @dotnet/jit-contrib

[am11]

@sandreenko, would it also fix #1368, since fgAddrCouldBeNull has:

runtime/src/coreclr/src/jit/flowgraph.cpp

Lines 7327 to 7330 in 3d20030

	elseif (addr->OperIs(GT_CNS_STR))
	{
	returnfalse;
	}

[EgorBo]

@sandreenko, would it also fix #1368, since fgAddrCouldBeNull has:

runtime/src/coreclr/src/jit/flowgraph.cpp

Lines 7327 to 7330 in 3d20030

	elseif (addr->OperIs(GT_CNS_STR))
	{
	returnfalse;
	}

yeah that one is already fixed

[EgorBo]

@sandreenko Since you touch it, could you please address #37245 (comment) as part of this PR? 🙂

[sandreenko]

@sandreenko Since you touch it, could you please address #37245 (comment) as part of this PR? 🙂

Sure, done

[AndyAyersMS]

I wonder if we can do something similar over in gtTryRemoveBoxUpstreamEffects -- it currently create an implicit null check, and does not check for the same "can optimize away the check" cases that the importer pattern match does.

@erozenfeld may have already tried this.

[sandreenko]

I wonder if we can do something similar over in gtTryRemoveBoxUpstreamEffects -- it currently create an implicit null check, and does not check for the same "can optimize away the check" cases that the importer pattern match does.

I pushed a change with the same check for gtChangeOperToNullCheck. It should cover all cases where we create null-checks. So we will see missed-optimization opportunities as asserts if they appear.

[sandreenko]

I pushed a change with the same check for gtChangeOperToNullCheck. It should cover all cases where we create null-checks. So we will see missed-optimization opportunities as asserts if they appear.

Actually, I remember that I was trying to do that in the past and it did not work.
We call TransformUnusedIndirection that changes 'IND' to 'NULLCHECK' from different phases and each phase requires different transformations to delete IND and ADDR when ADDR can't be null. I have dropped the check in gtChangeOperToNullCheck, @AndyAyersMS should I open an issue to track this possible optimization in the future?

[AndyAyersMS]

should I open an issue to track this possible optimization

Seems like a good idea. Would be good to note more details on why it's not as simple as it might seem.