CG2 Add lazy string literal loading support

[nattress]

• Currently all string literals are loaded as method load pre-code fixups.
• Match CG1 implementation and allow the JIT to use lazy string literal resolution so cold code strings are lazy loaded.

[nattress]

cc @dotnet/crossgen-contrib

[jkotas]

I do not think it is as simple as this. There needs to be a code to add the current module argument for the helper (it is what ZapLazyHelperThunk does in crossgen1.

[nattress]

Ah, I thought the CORINFO_HELP_STRCNS_CURRENT_MODULE meant we didn't need that. I'll look into adding that lazy thunk.

[trylek]

I think that ImportThunk already has a Lazy variant that I think was supposed to cater for lazy strings, among others. Having said that, it hasn't been tested until now so there's a high chance of it being broken in some way.

[nattress]

Thanks Tomas - I corrected things to call the lazy thunk and fixed an x64 bug. I'll kick off a CG2 run to make sure we're okay on other architectures.

[jkotas]

Is this right for strings from other modules? Crossgen1 version of this method has a check for current module in this method.

[nattress]

I believe that's a fragile ngen scenario. getLazyStringLiteralHelper gets called from the below handling code in the JIT. Returning CORINFO_HELP_STRCNS causes the JIT to call embedModuleHandle which is not supported in R2R.

runtime/src/coreclr/jit/morph.cpp

Lines 9287 to 9301 in 1390941

	CorInfoHelpFunc helper = info.compCompHnd->getLazyStringLiteralHelper(tree->AsStrCon()->gtScpHnd);
	if (helper != CORINFO_HELP_UNDEF)
	{
	// For un-important blocks, we want to construct the string lazily
	GenTreeCall::Use* args;
	if (helper == CORINFO_HELP_STRCNS_CURRENT_MODULE)
	{
	args = gtNewCallArgs(gtNewIconNode(RidFromToken(tree->AsStrCon()->gtSconCPX), TYP_INT));
	}
	else
	{
	args = gtNewCallArgs(gtNewIconNode(RidFromToken(tree->AsStrCon()->gtSconCPX), TYP_INT),
	gtNewIconEmbScpHndNode(tree->AsStrCon()->gtScpHnd));
	}

[jkotas]

Does this all work well for large version bubble or composite mode cases?

[trylek]

LGTM, thank you! Could you please address JanK's concerns by running a private composite Crossgen2 lab run on the change?

[nattress]

I'm abandoning this change. I initially made it to reduce file size; however the generated code is larger than the savings from removing a method pre-code fixup. In their current form lazy string literals are only used for string literals in catch blocks so the optimization is a marginal one anyway.

[jkotas]

lazy string literals are only used for string literals in catch blocks

Lazy string literals are used in throw blocks. They are startup time and working set optimization. We may want to measure how much startup time and working set we are giving up by not implementing them.