[RISC-V] Use zero register as argument for atomics #112693
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
the
community-contribution
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
| // Return Value: | ||
| // Whether the floating-point immediate can be synthesized with one instruction | ||
| // | ||
| static bool isSingleInstructionFpImm(double value, emitAttr size, int64_t* outBits) |
There was a problem hiding this comment.
68730b3 is being scheduled for building and testingGIT: |
|
/azp run runtime |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/ba-g Failures are unrelated infra issues |
| // Return Value: | ||
| // Whether the floating-point immediate can be synthesized with one instruction | ||
| // | ||
| static bool isSingleInstructionFpImm(double value, emitAttr size, int64_t* outBits) |
There was a problem hiding this comment.
Would it be more useful to return out some enum that indicates if we're doing, none, Simm12, or Simm20 instead of the bool?
There is significant coupling of the callers to this and them subsequently doing the same isValidSim12 and/or isValidSimm20 to emit the actual code. Might be really nice to return which and not test the bits there too...
There was a problem hiding this comment.
I thought about it but it complicated the signature of this simple helper, besides LSRA doesn't need to know which instruction will be used.
A zero constant was unnecessarily synthesized, wasting a register.
Also fix a non-obvious bug in CompareExchange with unextended comparand register (see added test case).
Part of #84834, cc @dotnet/samsung