为什么.NET CLR无法正确内联标记AggressiveInlining的方法？

• 常量移位与变量移位的固有差异：手动内联的版本使用固定移位常量1，JIT可直接生成单条立即数移位指令rol qword ptr [rdx],1。而调用RotateLeft时传入的是变量curIndex，x86架构规定变量移位必须使用cl寄存器存储移位值，必然会多出mov ecx,r9d这类寄存器赋值指令，和内联是否生效无关。你看到的.NET Framework 4.7.2下带AggressiveInlining标记的版本实际已经完成内联，没有函数调用开销，额外指令是变量移位的必要操作，就算手动内联变量移位场景，生成的汇编也完全一致。
• ref参数提升内联成本阈值：当前RotateLeft使用ref ulong作为参数，.NET JIT的内联判定规则中，带引用参数的小函数会提高内联成本阈值，.NET Framework和早期.NET Core版本更容易判定为不满足内联条件。
• .NET 5分层编译的临时未优化代码：你贴出的.NET 5下带call指令的汇编是Tier0（快速编译层）生成的未优化代码，分层编译默认开启时，方法第一次运行会先生成低优化级别的代码，后续后台编译的Tier1版本才会应用AggressiveInlining标记完成内联。

1. 修改RotateLeft为返回值实现：放弃ref参数，直接返回处理后的ulong值，大幅降低内联成本，内联成功率接近100%：

[MethodImpl(MethodImplOptions.AggressiveInlining)]
private ulong RotateLeft(ulong hash, int by)
{
    // 显式做位与保证移位位数合法，帮助JIT优化
    by &= 0x3F;
    return (hash << by) | (hash >> (64 - by));
}

// 调用方式调整为赋值模式
hash = RotateLeft(hash, curIndex);

2. 使用.NET官方内置的硬件优化方法：.NET Core 3.0及以上版本提供System.Numerics.BitOperations.RotateLeft，该方法是JIT内置识别的硬件intrinsic，会直接生成单条rol指令，不需要自行封装，零额外开销。
3. 针对.NET 5+的额外优化选项：
   • 可以在高频调用的哈希方法上添加[MethodImpl(MethodImplOptions.AggressiveOptimization)]标记，跳过Tier0快速编译层，直接生成高度优化的汇编代码
   • 升级到.NET 6及以上版本，JIT的内联判定和优化能力有大幅提升，这类小函数的内联成功率几乎为100%

内容的提问来源于stack exchange，提问作者Bryce Wagner