Add long/ulong->float cast helpers

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered

[saucecontrol]

Resolves#106646

We currently have a few inconsistencies in the way long/ulong to float conversions are done in JIT.

Problem 1

On 64-bit platforms, long->float conversions have always been done directly with a native CPU instruction, while on 32-bit, long->float has always been morphed to long->double->float so that it could use CORINFO_HELP_LNG2DBL.

This can lead to different conversion results when the long->double conversion rounds in a different direction than long->float would. Ex: sharplab.

Similarly, ulong->float may yield a different result than ulong->double->float.

Problem 2

In CIL, there is no way to represent a conversion directly from unsigned to float or double. The IL instruction conv.r.un specifies unsigned conversion to IL type F which is of indeterminate precision. Consequently, managed language compilers emit a pair of instructions for these casts: conv.r.un; conv.r4 or conv.r.un; conv.r8.

The JIT importer has always treated conv.r.un as unsigned->double, so in the case of conv.r.un; conv.r8, the second (double->double) cast is skipped, and the intention of the managed compiler is preserved. conv.r.un; conv.r4, on the other hand, imports as unsigned->double->float.

As stated above, this could yield a different result than intended for ulong.

Problem 3

When Arm64 support was added to JIT, as an optimization to take advantage of the fact Arm64 has a direct ulong->float conversion instruction, recognition of the ulong->double->float pattern was added to JIT, and the intermediate cast was removed. This led to Arm64 having different cast behavior than all other platforms.

#84384 extended the same optimization to x64 in .NET 8, using AVX-512 instructions. This led to further fragmentation of behavior since the presence or absence of AVX-512 could change results.

#111595 unified the behavior on x64 by emulating the direct ulong->float cast using SSE instructions.

However, this still leaves problem 1 (32-bit still goes through CORINFO_HELP_ULNG2DBL) and introduces another: The intermediate double cast may have actually been intentional, and the current optimization removes it without knowing. i.e. conv.r.un; conv.r4 and conv.r.un; conv.r8; conv.r4 are treated the same.

The solution

This PR adds JIT helpers to perform long->float and ulong->float casts directly for 32-bit platforms.

It also modifies JIT to specifically look for the conv.r.un; conv.r4 sequence and import it as unsigned->float, and then calls the new helpers as appropriate.

Next steps

Because this requires a JIT-EE GUID change, I have broken the solution into two parts.

This part solves problems 1 and 2 by making sure all platforms can consistently recognize and perform the long/ulong->float casts directly.

I will address problem 3 in a followup PR, along with some more cleanup, optimization, and added tests. The current bad optimization also catches some redundant casts that will need to be handled differently, and it will be easier to see the impact of all those changes if the SPMI asmdiff jobs work.

[AaronRobinsonMSFT]

/cc @dotnet/jit-contrib

[dotnet-policy-service]

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

[saucecontrol]

jit-format is failing due to changes from #114525. cc @kunalspathak

(fixed in #114603)

[jkotas]

The VM side of the changes LGTM

[BruceForstall]

@saucecontrol Please merge and resolve conflicts.

[tannergooding]

CC. @dotnet/jit-contrib, @jakobbotsch for secondary review

[EgorBo]

LGTM, let's just in case kick off a few outerloops

[EgorBo]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, Fuzzlyn, runtime-coreclr jitstress-isas-avx512

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[tannergooding]

Failures are unrelated. Logged issues for the new ones Fuzzlyn discovered