JIT: don't kill FP/SIMD/mask regs across x64 write barriers by EgorBo · Pull Request #128778 · dotnet/runtime

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

EgorBo · 2026-05-29T16:56:57Z

What I deliberately did not do

Did not exclude RCX/RDI (dst) from the kill set — the asm helpers shift dst in place (shr rcx, 0Bh), so it must be considered clobbered. Preserving dst would require rewriting all ~20 asm variants.
Did not exclude RDX/RSI (src) — the Region variants destroy src.
Did not exclude R10/R11 on Windows even though the default patched-slot path doesn't touch them. Kept conservative to cover _DEBUG runtime variant (JIT_WriteBarrier_Debug) and the DOTNET_UseGCWriteBarrierCopy=0 config (RhpAssignRef), both of which touch R10/R11.

PS: We probably can do this for APX cc @dotnet/intel

I think it would be nice to preserve dst register unchanged (we do that for arm64), but that requires some changes in the ASM helpers.

The x64 JIT_WriteBarrier / JIT_CheckedWriteBarrier helpers (and all the patched-slot variants: PreGrow/PostGrow/SVR/Region + WriteWatch flavors) never execute any SSE/AVX/AVX-512/EVEX-mask instruction. So XMM/YMM/ZMM and K mask registers can stay live across a write barrier call. Narrow RBM_CALLEE_TRASH_WRITEBARRIER (and the matching GCTRASH mask) from the full RBM_CALLEE_TRASH down to RBM_INT_CALLEE_TRASH_INIT on amd64. Integer callee-trash regs remain conservatively in the kill set to keep _DEBUG runtime builds and DOTNET_UseGCWriteBarrierCopy=0 working. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dotnet-policy-service · 2026-05-29T16:58:23Z

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

Copilot

Pull request overview

This PR narrows the amd64 JIT write-barrier register kill masks so FP/SIMD/mask registers can remain live across CORINFO_HELP_ASSIGN_REF and CORINFO_HELP_CHECKED_ASSIGN_REF, matching the documented helper ABI and reducing unnecessary spills.

Changes:

Documents the amd64 write-barrier helper register preservation/clobbering contract.
Changes amd64 write-barrier trash and GC-trash masks from full callee-trash to integer-only initial callee-trash registers.
Keeps conservative integer clobbers for runtime/debug write-barrier variants.

EgorBo · 2026-05-29T17:53:16Z

@MihuBot

VSadov · 2026-05-30T01:02:52Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?

For context:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

EgorBo · 2026-05-30T01:14:15Z

Will this require write barriers that need to call into C++ code on some paths to spill more around the calls?
For context: https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/amd64/WriteBarriers.asm#L517-L526

Probably not since we cannot guarantee what is happening in a code compiled by C++. But if that is an issue we need a new JIT-EE API, because we already precisely track registers used by WB on arm64 today (and just removing that will lead to quite big regressions) and we've always been doing that for byref WB that I deleted recently

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

kg

vsadov's comment occurred to me as well, but otherwise this looks okay to me

VSadov · 2026-06-01T15:27:19Z

What bothers me a bit is that this just encodes the current implementation that happens to be. If the eventual goal is to be able to switch GCs without rebuilding the entire runtime, the barrier calling conventions should be more "designed".

We already have to spill a lot more on arm64:
https://github.com/dotnet/runtimelab/blob/97a242e8b9a66df1f9de9ff16fc24c42035bcc98/src/coreclr/runtime/arm64/WriteBarriers.asm#L598-L609

 ;; because of the barrier call convention ;; we need to preserve caller-saved x0 through x15 and x29/x30 stp x29,x30,[sp,-16*9]! stp x0, x1,[sp,16*1] stp x2, x3,[sp,16*2] stp x4, x5,[sp,16*3] stp x6, x7,[sp,16*4] stp x8, x9,[sp,16*5] stp x10,x11,[sp,16*6] stp x12,x13,[sp,16*7] stp x14,x15,[sp,16*8]

On x64 the spill used to be fairly minimal in comparison.
Either way kind of worked, but which way is better? Are we trading binary size for throughput here?

Calls into C++ code are not on common hot paths, but even on uncommon paths spilling too much may become measurable.

I think we may want to revisit the barriers calling convention is at some point.

EgorBo · 2026-06-01T15:46:10Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have.
BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).

Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

VSadov · 2026-06-01T17:58:02Z

@VSadov I think we just need a JIT-EE API that will tell the JIT about the calling convention for write barriers (e.g. eithe just normal or custom) and Satori can return "normal" (on both x64 and arm64) and remove that spilling logic you have. BTW, are you sure you also don't need to spill SIMD regs there? Because I think arm64 JIT assumes they're not killed too today, but it's possible that your C++ call just never use them either (but not something you can rely on).
Custom calling convention seems to be very proftiable, e.g. in this PR I tried just to avoid touching RCX/RDI reg (typically holding this) and got massive diffs in SPMI (-2.0Mb on SysV and -1.3Mb on win-x64).

I think standard calling convention may be too generous towards GC barriers. I understand the desire to leave registers for JIT to use.

However, the current conventions could be:

too tight that the asm part of the barrier may need to push/pop for extra temps.
unfriendly to C++ code.

It may be a good idea to make it configurable via JIT-EE API.
And I assume crossgen could just use the most conservative "common denominator" combination.

BTW, are you sure you also don't need to spill SIMD regs there?

We rely on C++ code that we call to not trash SIMD (by manual examination). On x64 we spill XMM0, because it does.
It is a bit of playing with fire.

SIMD is probably where I'd put the line. Spilling the whole SIMD context could be expensive, while chance of it used while calling a barrier are not high.

To be fair - the effects were never a target of too much research/measuring. Perhaps the current scheme is even completely OK.

EgorBo · 2026-06-01T18:03:14Z

@VSadov It should be trivial to implement the JIT-EE I think, I can give it a try if Satori is anywhere near to be productized/merged into dotnet/runtime, something like CORINFO_WRITEBARRIER_CALLC getWriteBarrierCallingConvention();

The reason I decided to tune the registers for WB are potential regressions from my other change to remove CORINFO_HELP_ASSIGN_BYREF (#128542 + #128687) because that WB had a very compact calling convention with no spills between calls at all

jkotas · 2026-06-01T18:37:05Z

We rely on C++ code that we call to not trash SIMD (by manual examination).

We used to do that in a few places and learned hard way that it is a bad idea...

EgorBo · 2026-06-02T21:02:32Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)

I'm merging it to match the behavior with arm64

VSadov · 2026-06-02T22:29:30Z

@VSadov let me know if you want me to introduce an API that can switch CC for WB between this custom and standard (if we sure we'll merge Satori into runtime eventually)
I'm merging it to match the behavior with arm64

I'll let you know. Right now Satori is a bit behind main. I think we will need to catch up to the state just before this PR first. (deleting byref barriers might be a good thing in terms of reducing complexity).

CopilotAI review requested due to automatic review settings May 29, 2026 16:56

Copilotstarted reviewing on behalf of EgorBo May 29, 2026 16:57 View session

github-actionsBot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 29, 2026

dotnet-policy-serviceBot assigned EgorBo May 29, 2026

CopilotAI reviewed May 29, 2026
View reviewed changes

MihuBot mentioned this pull request May 29, 2026
[JitDiff X64] [EgorBo] JIT: don't kill FP/SIMD/mask regs across x64 write ba ... MihuBot/runtime-utils#1950
Open

Merge branch 'main' into jit-wb-preserve-fp
bf7e6ee

Merge branch 'main' into jit-wb-preserve-fp
7fead2b

CopilotAI review requested due to automatic review settings May 30, 2026 01:16

Copilotstarted reviewing on behalf of EgorBo May 30, 2026 01:16 View session

CopilotAI reviewed May 30, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/targetamd64.h

tannergooding reviewed May 30, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/targetamd64.h

tannergooding approved these changes May 30, 2026
View reviewed changes

tannergooding reviewed May 30, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/targetamd64.h

build-analysisBot mentioned this pull request May 30, 2026
XHarness package install failure on iOS due to devicectl NSPOSIXErrorDomain error 49 #123796
Open

kg approved these changes Jun 1, 2026
View reviewed changes

EgorBo enabled auto-merge (squash) June 2, 2026 21:01

EgorBo merged commit db87610 into dotnet:mainJun 2, 2026
131 of 139 checks passed

dotnet-maestroBot mentioned this pull request Jun 3, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#6997
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 3, 2026

jakobbotsch mentioned this pull request Jun 8, 2026
[ci-scan] Test failure: NumberHandlingTests_Metadata.Number_AsCollectionElement_RoundTrip on NativeAOT windows-x64 #129010
Closed

github-actionsBot locked and limited conversation to collaborators Jul 3, 2026