runtime: Performance regression: float.ToString(format) 20% to 3x slower

We’re in the prolog, so making calls is problematic. It requires special care and usually some kind of bespoke calling convention (some native compilers do this for stack checks, for instance).

There’s nothing blocking us from generating different code to zero the slots. We are not GC live at this point so can use whatever instructions will work. But we also would like to minimize the set of registers used and any shuffling needed around the zeroing sequence. For example REP STOS needs RCX which is usually live at this point – so almost certainly the current heuristic is underestimating the cost of this kind of loop. It is worse on SysV.

So I think the way forward is

• review heuristics for when to generate block stores for prolog zeroing, especially cases when there are structs with both GC and non-GC fields. Likely we should be generating inline sequences for more cases than we do now.
• enable use of wider stores (say via XMM) to zero slots (which can decrease cost of inline sequences and make their use even more widespread) and update the heuristic accordingly.
• reconsider whether all these stack slots really need to be untracked lifetimes. In some cases we might be able to defer the zeroing until sometime later in the method, or avoid it all together.

The extra prolog costs that come up because a struct is used somewhere in the method can make it hard to reason about struct perf.

GCC simply reuses the reminder returned by the DIV instruction.

My mistake, looks like it did pick it up

G_M61719_IG01:
       push     rbp
       push     r15
       push     r14
       push     rdi
       push     rsi
       push     rbx
       sub      rsp, 168
       movaps   qword ptr [rsp+90H], xmm6
       lea      rbp, [rsp+30H]
       xorps    xmm4, xmm4
       movaps   xmmword ptr [rbp+10H], xmm4
       movaps   xmmword ptr [rbp+20H], xmm4
       movaps   xmmword ptr [rbp+30H], xmm4
       movaps   xmmword ptr [rbp+40H], xmm4
       xor      rax, rax
       mov      qword ptr [rbp+50H], rax
       mov      rax, qword ptr [(reloc)]
       mov      qword ptr [rbp+08H], rax
       mov      rbx, rcx
       mov      rsi, r8
       mov      rdi, r9
       movaps   xmm6, xmm1

That sounds good/reasonable to me. It will also likely improve perf of various methods that are attempting to utilize things like Span/ValueStringBuilder as a perf optimization.

I’m going to mark this as future – nothing obvious for 3.0 jumps out here. I’ll keep looking though.