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][jit] Add Vector128.WithElement as intrinsic on arm64. #85158

Merged
merged 3 commits into from
Apr 26, 2023

Conversation

jandupej
Copy link
Member

@jandupej jandupej commented Apr 21, 2023

This enables Vector128.WithElement intrinsic and lowers it as follows or arm64:

  • if index is a constant and in range, emits one mov and one ins and omits a bound check
  • if index is a constant and out of range, does the same as above but includes a bounds check
  • if T is 64-bit, emits a conditional branch that selects one of two ins (for lower or upper half) and includes a bounds check. A maximum of 5 instructions are emitted.
  • otherwise, creates a new vector global, gets its address, writes the original data there, overwrites the selected element with the replacement value and reads back. A bounds check is also included.

The last case is not very efficient; however given that the case should be uncommon, it is probably not a big issue.

Contributes to #80566

Comment on lines +2049 to +2052
if (index < 0 || index >= elems) {
MONO_EMIT_NEW_BIALU_IMM (cfg, OP_COMPARE_IMM, -1, args [1]->dreg, elems);
MONO_EMIT_NEW_COND_EXC (cfg, GE_UN, "ArgumentOutOfRangeException");
}
Copy link
Member

Choose a reason for hiding this comment

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

Is the comparison needed here since we know the exception is deterministically going to happen?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good point. I'll make this an unconditional throw.

Copy link
Member Author

Choose a reason for hiding this comment

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

It seems we do not have an opcode to unconditionally throw an exception. IMO adding it would be out of this PR's scope. Having the comparison in place should not hurt the normal execution path. So I propose adding an issue for the new opcode and deferring this optimization until it is in place. Are you OK with that? @tannergooding @vargaz

Copy link
Member

@tannergooding tannergooding left a comment

Choose a reason for hiding this comment

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

Changes overall LGTM. Just had a question and a suggestion for an optimization that can still be done.

@jandupej
Copy link
Member Author

CI failures are known issues and unrelated to this PR.

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