ImproveComments - making sure the comment is accurately describing the code

[cshung]

According to my understanding, the code is allowing platform-specific hardware-intrinsics to be compiled if it is in CoreLib by not entering that branch and throws.

[MichalStrehovsky]

CoreLib versioning with the runtime is the reason why have don't throw for Vector64/128/256 use in CoreLib here:

coreclr/src/vm/methodtablebuilder.cpp

Lines 9582 to 9587 in b18bb0b

	// We can allow these to AOT compile in CoreLib since CoreLib versions with the runtime.
	if (!IsNgenPDBCompilationProcess() &&
	GetAppDomain()->ToCompilationDomain()->GetTargetModule() != g_pObjectClass->GetModule())
	{
	COMPlusThrow(kTypeLoadException, IDS_EE_HWINTRINSIC_NGEN_DISALLOWED);
	}

It's not the reason in this spot.

I don't recall the reason for this one but you can probably find it in the 100+ comments on #24689 and #24917 if you want. I think it was just a risk-limiting thing because we were late in the cycle.

[MichalStrehovsky]

Oh right, I just remembered. We don't allow any intrinsic pregeneration outside CoreLib because the way we do it for CoreLib is that we prevent intrinsic expansion of the IsSupported checks and make that check JITted.

This works great for code that properly guards things with IsSupported. But code that doesn't guard things with IsSupported would get illegal instruction traps instead of PlatformNotSupportedException when the CPU doesn't support it. Those are harder to debug so we limit the risk of customers running into that in their code by just making everything jitted.

[cshung]

Thanks for the explanation, it makes sense. I tried to summarize it as succinctly as I can, can you please take a look again?

[MichalStrehovsky]

Thanks for improving the comment!