Improve RegexCompiler's ToLower perf

[stephentoub]

Profiling shows that RegexOptions.Compiled | RegexOptions.IgnoreCase regexes are spending a non-trivial amount of time invoking char.ToLower(c, _culture), and a good chunk of this is just in making the virtual call to _culture.TextInfo inside of char.ToLower. Instead of caching a CultureInfo and calling char.ToLower(c, _culture), RegexCompiler can cache the TextInfo once and then call _textInfo.ToLower(c), saving a virtual call on every character comparison.

That's the second commit. The first commit addresses why this change hasn't been done until now. We'd previously made the same change in RegexInterpreter, but in RegexCompiler, we need a temporary in order to swap parameters to make the ToLower lower call (by the time CallToLower is invoked, the char is already on the evaluation stack). So, the first commit fixes how RegexCompiler manages temporary locals. Previously, the developer would declare a few temporary locals at the beginning of the method, and then manually figure out how to use them in a safe manner. With this change, we instead maintain a pool of locals that can be rented from just where they're needed. That makes it possible for a helper like CallToLower to just grab a local for the brief period it needs one.

This PR handles the RegexOptions.IgnoreCase scenario. #35194 covers the RegexOptions.IgnoreCase | RegexOptions.InvariantCulture scenario, as there RegexCompiler uses ToLowerInvariant.

Review without whitespace diffs: https://github.com/dotnet/runtime/pull/35203/files?w=1
cc: @GrabYourPitchforks, @eerhardt, @pgovind

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Text.RegularExpressions;

public class Program
{
    static void Main(string[] args) => BenchmarkSwitcher.FromAssemblies(new[] { typeof(Program).Assembly }).Run(args);

    private readonly Regex _regex = new Regex("Hello, \\w+.", RegexOptions.Compiled | RegexOptions.IgnoreCase);
    private readonly string _input = new string("This is a test to see how well this does.  Hello, DotNetBot.");

    [Benchmark] public bool Test() => _regex.IsMatch(_input);
}

Method	Job	Toolchain	Mean	Error	StdDev	Ratio
Test	Job-ABLHBF	\master\corerun.exe	207.0 ns	0.42 ns	0.37 ns	1.00
Test	Job-VWJGVI	\pr\corerun.exe	149.9 ns	0.33 ns	0.25 ns	0.72

[ghost]

Tagging subscribers to this area: @eerhardt
Notify danmosemsft if you want to be subscribed.

[GrabYourPitchforks]

@stephentoub We recently changed TextInfo.ToUpper(char) / ToLower(char) to be non-virtual. Is this something you could take advantage of in your code by emitting call instead of callvirt? Or do you need to retain compatibility with downlevel platforms?

(Edit: I suppose you might be relying on the implicit null check that callvirt performs.)

[eerhardt]

This looks super clean. I like how this turned out vs the 3 _tempXLocal variables.

[eerhardt]

(super nit) Rents an ReadOnlySpan => Rents a ReadOnlySpan

[stephentoub]

Thanks. I'll fix the comment in the other PR, to avoid restarting CI.

[stephentoub]

We recently changed TextInfo.ToUpper(char) / ToLower(char) to be non-virtual. Is this something you could take advantage of in your code by emitting call instead of callvirt? Or do you need to retain compatibility with downlevel platforms? (Edit: I suppose you might be relying on the implicit null check that callvirt performs.)

It'll still invoke it non-virtually, and potentially even inline it; it'll just include the null check if needed. You think it's worthwhile changing it to be call instead? Last I knew, in general the C# compiler emits callvirt even for non-virtual methods, except in some circumstances, such as with the ?. operator.

If we want to change it, I think we should change other uses of callvirt as well, e.g. various string methods are currently invoked with callvirt instead of call:

runtime/src/libraries/System.Text.RegularExpressions/src/System/Text/RegularExpressions/RegexCompiler.cs

Line 528 in 774daf4

Callvirt(s_stringGetCharsMethod);