[RISC-V] Optimize redundant sext.w generation in GT_JCMP codegen

[namu-lee]

There was an issue when emitting instructions for GT_JCMP nodes: 4-byte operands are always sign-extended before the comparison.

The commit suppresses emitting the 'sext.w' if the last instruction has already sign-extended the operands of JCMP. It cannot optimize out the sign-extension if a previously sign-extending instruction is not emitted right before the emission of the JCMP instruction, as it is implemented as a peephole optimization to conservatively preserve type safety.

The optimization slightly improves the performance of loop-intensive benchmark by reducing the instruction count of hot code, while not affecting the jit workload time.

@clamp03 @tomeksowi @SkyShield, @credo-quia-absurdum
part of #84834, cc @dotnet/samsung

[Copilot]

Pull Request Overview

This PR optimizes RISC-V code generation by eliminating redundant sign-extension instructions (sext.w) in jump comparison (GT_JCMP) nodes. The optimization detects when a previous instruction has already sign-extended a register and avoids emitting another sign-extension instruction immediately after.

Key changes:

• Added peephole optimization to detect redundant sign-extension instructions
• Implemented helper functions to identify instructions that perform sign-extension
• Applied the optimization in three specific code paths within jump comparison generation

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/coreclr/jit/emitriscv64.h	Added function declarations for sign-extension detection and redundancy checking
src/coreclr/jit/emitriscv64.cpp	Implemented emitInsIsSignExtend and isRedundantSignExtend helper functions
src/coreclr/jit/codegenriscv64.cpp	Applied redundant sign-extension optimization in jump comparison code generation

[dotnet-policy-service]

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

[clamp03]

Please check jit-format errors and fix them.

[tomeksowi]

#118270 already removes some of the unnecessary sign-extensions. And not just for JCMP but for integer comparisons in general.

The problem with peep-hole'ing the instruction stream is that the argument may not be calculated in the last instruction. I also predict a problem with using full-register instruction variants for 32-bit values if possible (they have better compressed encodings, we may choose to do such optimizations in the future). It also won't recognize that integer primitive arguments are passed to functions sign-extended because the calling convention requires so.

I think the cost of added sign-extension nodes won't be high in the long run because the places where sign-extension is necessary are generally an exception, most 32-bit operations should already be sign-extended.

[namu-lee]

#118270 already removes some of the unnecessary sign-extensions. And not just for JCMP but for integer comparisons in general.

The problem with peep-hole'ing the instruction stream is that the argument may not be calculated in the last instruction. I also predict a problem with using full-register instruction variants for 32-bit values if possible (they have better compressed encodings, we may choose to do such optimizations in the future). It also won't recognize that integer primitive arguments are passed to functions sign-extended because the calling convention requires so.

I think the cost of added sign-extension nodes won't be high in the long run because the places where sign-extension is necessary are generally an exception, most 32-bit operations should already be sign-extended.

Sorry I missed checking your PR. Closing this.