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

Intrinsify RuntimeHelpers.CreateSpan on Mono #80762

Closed
Tracked by #43051
EgorBo opened this issue Jan 18, 2023 · 8 comments · Fixed by #82093
Closed
Tracked by #43051

Intrinsify RuntimeHelpers.CreateSpan on Mono #80762

EgorBo opened this issue Jan 18, 2023 · 8 comments · Fixed by #82093
Assignees
Milestone

Comments

@EgorBo
Copy link
Member

EgorBo commented Jan 18, 2023

Context: a lot of benchmarks regressed on Mono after #79461 and #80668

On CoreCLR the following snippet (compiled with the most recent Roslyn):

static int GetInt8(int index)
{
    ReadOnlySpan<byte> RVA = new byte[] { 1, 2, 3, 4 };
    return RVA[index];
}

static int GetInt32(int index)
{
    ReadOnlySpan<int> RVA = new int[] { 1, 2, 3, 4 };
    return RVA[index];
}

produces more or less the same codegen while IL is quite different - in case of ReadOnlySpan<int> a RuntimeHelpers.CreateSpan call is emitted by Roslyn (to handle endianness). CoreCLR has a JIT intrinsics implemented by @davidwrighton in #61079 that helps it to achieve perfect codegen here. As that PR states, Mono doesn't have that intrinsic so CreateSpan ends up calling an icall in vm (ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_GetSpanDataFrom)

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 18, 2023
@ghost ghost added the untriaged New issue has not been triaged by the area owner label Jan 18, 2023
@ghost
Copy link

ghost commented Jan 18, 2023

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

Issue Details

Context: a lot of benchmarks regressed on Mono after #79461 and #80668

On CoreCLR the following snippet (compiled with the most recent Roslyn):

static int GetInt8(int index)
{
    ReadOnlySpan<byte> RVA = new byte[] { 1, 2, 3, 4 };
    return RVA[index];
}

static int GetInt32(int index)
{
    ReadOnlySpan<int> RVA = new int[] { 1, 2, 3, 4 };
    return RVA[index];
}

produces more or less the same codegen while IL is quite different - in case of ReadOnlySpan<int> a RuntimeHelpers.CreateSpan call is emitted by Roslyn (to handle endianness). CoreCLR has a JIT intrinsics implemented by @davidwrighton in #61079 that helps it to achieve perfect codegen here. As that PR states, Mono doesn't have that intrinsic so CreateSpan ends up calling an icall in vm (ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_GetSpanDataFrom)

Author: EgorBo
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@ghost
Copy link

ghost commented Jan 18, 2023

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

Issue Details

Context: a lot of benchmarks regressed on Mono after #79461 and #80668

On CoreCLR the following snippet (compiled with the most recent Roslyn):

static int GetInt8(int index)
{
    ReadOnlySpan<byte> RVA = new byte[] { 1, 2, 3, 4 };
    return RVA[index];
}

static int GetInt32(int index)
{
    ReadOnlySpan<int> RVA = new int[] { 1, 2, 3, 4 };
    return RVA[index];
}

produces more or less the same codegen while IL is quite different - in case of ReadOnlySpan<int> a RuntimeHelpers.CreateSpan call is emitted by Roslyn (to handle endianness). CoreCLR has a JIT intrinsics implemented by @davidwrighton in #61079 that helps it to achieve perfect codegen here. As that PR states, Mono doesn't have that intrinsic so CreateSpan ends up calling an icall in vm (ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_GetSpanDataFrom)

Author: EgorBo
Assignees: vargaz, BrzVlad
Labels:

area-Codegen-JIT-mono, area-Codegen-AOT-mono, area-Codegen-Interpreter-mono

Milestone: 8.0.0

@lewing
Copy link
Member

lewing commented Jan 18, 2023

@SamMonoRT
Copy link
Member

@jandupej has started work on addressing this

@jandupej
Copy link
Member

The issue has been addressed in #81695, closing.

@vargaz
Copy link
Contributor

vargaz commented Feb 13, 2023

The interpreter support is still missing.

@SamMonoRT
Copy link
Member

@BrzVlad will be working on Interpreter support

@vargaz vargaz reopened this Feb 13, 2023
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Feb 14, 2023
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Feb 15, 2023
@jandupej
Copy link
Member

Remaining perf issues on Linux AOT x64: #83330

@ghost ghost locked as resolved and limited conversation to collaborators Apr 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants