Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't inline expand boxes with many GC pointers #101669

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions src/coreclr/jit/importer.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -3174,6 +3174,17 @@ void Compiler::impImportAndPushBox(CORINFO_RESOLVED_TOKEN* pResolvedToken)
bool optForSize = !exprToBox->IsCall() && varTypeIsStruct(exprToBox) && opts.OptimizationDisabled();
bool expandInline = canExpandInline && !optForSize;

if (expandInline)
{
// After a certain number of GC pointers, the write barriers used
// in inline expansion stop being profitable.
ClassLayout* layout = typGetObjLayout(pResolvedToken->hClass);
if (layout->GetGCPtrCount() > 3)
Copy link
Member

@EgorBo EgorBo Apr 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect this might need more work, e.g. when we box a struct with 4 fields but all of them are null or e.g. nongc strings - this will be a regression. Also, I suspect this might ruin some "optimize boxing" optimizations.

I think we need to either fix all those places to deal with a helper call or we need to emit a bulk copy in codegen, just like I did in #99096 (but to do it for batched-copy, not batched-precise-barrier).

{
expandInline = false;
}
}

if (expandInline)
{
JITDUMP(" inline allocate/copy sequence\n");
Expand Down
Loading