-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[RISC-V] Clean up NYI_RISCV64 in CodeGen and Emitter #94666
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
[RISC-V] Clean up NYI_RISCV64 in CodeGen and Emitter #94666
Conversation
In 6ca0784 commit, function genCodeForNegNot diverged from her LoongArch friend and didn't call genGetInsForOper since then. Therefore we can remove GT_NEG/GT_NOT integer cases and GT_NEG float case as there are all dead.
Given that such function doesn't make sense outside x86/x64 mov instruction context we can get rid of definition.
It looks like emitInsToJumpKind is helper function coming from ARM large jump handling logic. Currently RISC-V emitter doesn't rely on instruction format and probably won't need anything like ARM large jump handling.
For the cases when unreachability is easy to prove we can express that fact by using proper NO_WAY macro.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThis PR focus mostly on NYI_RISCV64s that are easy to fix, remove or classify as ones that will need more care in future. Part of #84834
|
When control flow reach needCheckOv in intConst block, only addi/addiw instructions can be handled there and first NYI_RISCV64 is redundant. Remaining condition statements starting with GT_MUL case can be replaced with more straightforward switch statement and then second NYI_RISCV64 is redundant.
0bdf685 to
b2c62ec
Compare
78c66d2 to
2f850d2
Compare
2f850d2 to
a0c4256
Compare
When no helper for codeKind is available we need to emit appropriate code directly.
a0c4256 to
78f90c7
Compare
|
@jakobbotsch Could you review this PR? Thank you. |
This PR focus mostly on NYI_RISCV64s that are easy to fix, remove or classify as ones that will need more care in future.
Part of #84834
cc @wscho77 @HJLeee @clamp03 @JongHeonChoi @t-mustafin @gbalykov @ashaurtaev @sirntar @tomeksowi @Bajtazar