Extend preinitialization arithmetic and string manipulation

[Suchiman]

After talking to Fabian on #allow-unsafe-blocks who trying to use preinitialization as const expressions for the purposes of obfuscating string literals, he encountered a few hurdles that were trivial to resolve:

Makes it possible to dynamically allocate and preinitialize those strings.
Extends arithmetic support to handle nint operator int32 operations (needed for string manip)
Adds xor / not / shr support and extends casting for floating point types

[dotnet-policy-service]

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

[EgorBo]

in the coreclr's interpreter we do this for IsReferenceOrContainsReferences:

    bool containsGcPtrs = typeArg->ContainsGCPointers();

    // Return true for byref-like structs with ref fields (they might not have them)
    if (!containsGcPtrs && typeArg->IsByRefLike())
    {
        containsGcPtrs |= HasByrefFields(typeArg);
    }

so have to be careful around byref-like structs (with byref fields)

[Suchiman]

I stole that code from here 1e0c243#diff-daf353351989087d61e8a1cb5e9c1434b14f16a5029cd38c8ce0037ed4685fa7L48 was that code wrong then?

[EgorBo]

I guess so? it's only recently it became possible with allow ref struct feature. Unless DefType.ContainsGCPointers already does what is needed..

[MichalStrehovsky]

Adding the extra opcodes looks reasonable to me. I feel a bit squeamish about the new intrinsics because of their bug potential.

This will need a lot more targeted testing. I assume this is only covered because String.Concat hits all of these. We'll want dedicated tests to hit all of these new instructions/instruction variants/intrinsics instead. At some point someone is going to optimize String.Concat codepaths with AVX5000 intrinsics, we'll no longer be able to preinitialize the API and the test will get deleted. We test the targeted IL building blocks instead to ensure coverage of the building blocks.

[Suchiman]

@MichalStrehovsky

I assume this is only covered because String.Concat hits all of these

correct

We'll want dedicated tests to hit all of these new instructions/instruction variants/intrinsics instead.

via the SmokeTests project? How would you test FastAllocateString and SpanHelpers.Memmove directly, which are not public APIs?

[MichalStrehovsky]

via the SmokeTests project? How would you test FastAllocateString and SpanHelpers.Memmove directly, which are not public APIs?

new string('\0', 10) might be a reasonable approximation for FastAllocateString testing and there's little chance for it to go wrong. SpanHelpers.Memmove is harder, that one I'm more squeamish about.

[jkotas]

Do we need a limit on the string size that can be allocated here? We do not want to OOM the compiler if somebody happens to create extremely long strings in the static constructors.

[dotnet-policy-service]

This pull request has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[dotnet-policy-service]

This pull request will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the pull request, but please note that it will be locked if it remains inactive for another 30 days.

[Fabi]

This pull request will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the pull request, but please note that it will be locked if it remains inactive for another 30 days.

:(