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

[mono] RuntimeHelpers.CreateSpan<T> is now intrinsic. #81695

Merged
merged 13 commits into from
Feb 13, 2023

Conversation

jandupej
Copy link
Member

@jandupej jandupej commented Feb 6, 2023

This addresses #80762.

@jandupej jandupej marked this pull request as ready for review February 8, 2023 13:34
@jandupej jandupej marked this pull request as draft February 8, 2023 13:35
@jandupej
Copy link
Member Author

jandupej commented Feb 8, 2023

/azp run extra-platforms

@azure-pipelines
Copy link

No pipelines are associated with this pull request.

@jandupej
Copy link
Member Author

jandupej commented Feb 8, 2023

/azp run runtime-extra-platforms

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jandupej
Copy link
Member Author

jandupej commented Feb 9, 2023

Some extra-platforms failures are due to #80976

// The following relies on the previous instruction being an OP_MOVE. Specifically. one that
// is emitted from CEE_TDTOKEN as the last EMIT_NEW_TEMPLOAD, which has its inst_p1 set.
// Bail out and use the non-intrinsic variant if this is not satisfied.
MonoClassField* field = (MonoClassField*) args [0]->inst_p1;
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks a little brittle, it depends on OP_VMOVE never having its inst_p1 set otherwise.

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess I could also use backend; the comments there do not indicate that the field is used with OP_VMOVE. Another way would be to do what you suggested earlier - emit a new opcode that would carry it in inst_p1 and then decompose it away. I had some issues getting that approach to work, so I tried this. It seems to work, although I cannot honestly verify that its inst_p1 is always untouched. Wouldn't that also be the case for the new opcode?

Copy link
Contributor

Choose a reason for hiding this comment

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

Using a new opcode would mean that this code could be sure that the input comes from the CEE_LDTOKEN code. The downside is that new opcode needs to be decomposed/lowered if its not followed by CreateSpan etc.

Copy link
Member Author

Choose a reason for hiding this comment

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

So now a OP_LDTOKEN_FIELD is emitted, which is equivalent in every way to a OP_VMOVE, except its opcode. This should protect the MonoInst contents until it is used by CreateSpan intrinsic. The decomposition of OP_LDTOKEN_FIELD is then only rewriting the opcode to OP_VMOVE.

int alignment = 0;
int element_size = mono_type_size (t, &alignment);

#if G_BYTE_ORDER == G_LITTLE_ENDIAN
Copy link
Contributor

Choose a reason for hiding this comment

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

This only needs to be called in the non-aot case.

MonoClassField* field_ref = mono_class_get_field_from_name_full (span->klass, "_reference", NULL);
MonoInst* ptr_inst;
if (cfg->compile_aot) {
EMIT_NEW_SFLDACONST (cfg, ptr_inst, field);
Copy link
Contributor

Choose a reason for hiding this comment

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

Will this work for these kinds of fields ? At runtime, the code in mono_resolve_patch_target_ext () gets executed to retrieve the field address, i.e. the
MONO_PATCH_INFO_SFLDA case.

Copy link
Member Author

Choose a reason for hiding this comment

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

I see there is also MONO_PATCH_INFO_RVA, maybe it would be more appropriate.

int alignment = 0;
int element_size = mono_type_size (t, &alignment);

#if G_BYTE_ORDER == G_LITTLE_ENDIAN
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
#if G_BYTE_ORDER == G_LITTLE_ENDIAN
#if G_BYTE_ORDER == G_LITTLE_ENDIAN

Copy link
Member Author

Choose a reason for hiding this comment

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

I have moved the preprocessor directives.


#if G_BYTE_ORDER == G_LITTLE_ENDIAN
int swizzle = 1;
#else
Copy link
Member

Choose a reason for hiding this comment

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

Ditto

int swizzle = 1;
#else
int swizzle = element_size;
#endif
Copy link
Member

Choose a reason for hiding this comment

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

Ditto

@@ -10820,9 +10820,12 @@ mono_method_to_ir (MonoCompile *cfg, MonoMethod *method, MonoBasicBlock *start_b
} else {
EMIT_NEW_PCONST (cfg, ins, handle);
}

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change

// This OP_LDTOKEN_FIELD later changes into a OP_VMOVE.
MonoClassField* field = (MonoClassField*) args [0]->inst_p1;
if (args [0]->opcode != OP_LDTOKEN_FIELD || !field || !field->type)
return NULL;
Copy link
Contributor

Choose a reason for hiding this comment

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

The !field etc. checks should not be needed any more.

@jandupej jandupej merged commit 7e154e1 into dotnet:main Feb 13, 2023
@jandupej jandupej deleted the issue80762 branch February 13, 2023 12:37
@ghost ghost locked as resolved and limited conversation to collaborators Mar 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants