Remove fgMorphCastedBitwiseOp

[EgorBo]

Seems like this opt is not very useful (only a few diffs in libraries.pmi and benchmarks), but at the same time it manages to significantly regress some benchmarks due to store-forward stalls #85957

Benchmark:

[Benchmark]
[Arguments(ulong.MinValue)]
[Arguments((ulong)12345)]
public bool FormatterUInt64(ulong value) => 
    Utf8Formatter.TryFormat(value, _destination, out _);

Method	Toolchain	value	Mean
FormatterUInt64	\Core_Root_base\corerun.exe	0	4.254 ns
FormatterUInt64	\Core_Root_PR\corerun.exe	0	1.620 ns
FormatterUInt64	\Core_Root_base\corerun.exe	12345	4.989 ns
FormatterUInt64	\Core_Root_PR\corerun.exe	12345	2.577 ns

It's not a solution for such stalls in JIT's codegen, but I don't see clear benefits in having this opt in JIT

[ghost]

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

Issue Details

---

Seems like this opt is not very useful (only a few diffs in libraries.pmi and benchmarks), but at the same time it manages to significantly regress some benchmarks due to store-forward stalls #85957

Benchmark:

[Benchmark]
[Arguments(ulong.MinValue)]
[Arguments((ulong)12345)]
public bool FormatterUInt64(ulong value) => 
    Utf8Formatter.TryFormat(value, _destination, out _);

Method	Toolchain	value	Mean
FormatterUInt64	\Core_Root_base\corerun.exe	0	4.254 ns
FormatterUInt64	\Core_Root_PR\corerun.exe	0	1.620 ns
FormatterUInt64	\Core_Root_base\corerun.exe	12345	4.989 ns
FormatterUInt64	\Core_Root_PR\corerun.exe	12345	2.577 ns

It's not a solution for such stalls in JIT's codegen, but I don't see clear benefits in having this opt in JIT

Author:	EgorBo
Assignees:	EgorBo
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@dotnet/jit-contrib @AndyAyersMS thoughts? I was thinking first to ignore NOL locals but to me the overall diffs aren't motivating enough to keep the optimizating judging that some of the "size improvements" actually regress perf

[jakobbotsch]

LGTM, given that it has low hits. We discussed a bit offline and long term we should probably also consider whether we should fix codegen for normalize-on-load locals to always do a small access.

[AndyAyersMS]

Yeah I think this is good. I looked to see if we missed spotting regressions back when this went in (#58727) but didn't find anything.

https://github.com/dotnet/perf-autofiling-issues/issues?q=is%3Aissue+created%3A2021-10-12..2021-10-19+label%3Aperf-regression+label%3Aarch-x64+label%3Aruntime-coreclr

[tannergooding]

Not for this PR, but is this something we can handle in lowering instead where we can make the decision to keep or bypass the cast based on whether the operands are coming from memory?

[EgorBo]

Probably, let's see if perf triage will find any regressions (hoping to see improvements instead)

[AndyAyersMS]

I wonder if we are seeing this on arm64 too. System.Buffers.Text.Tests.Utf8FormatterTests.FormatterInt64(value: 12345) is slower with PGO for win-x64, lin-x64, and lin-arm64.

The big drop on April 23 was from #85277 but it helped non PGO much more than PGO (we only had PGO data for win-x64 at that point)