loongarch: Add basic support for LoongArch32 #1837
Conversation
| /// Calculate the approximate double-precision result of dividing 1.0 by the square root | ||
| #[inline] | ||
| #[target_feature(enable = "frecipe")] | ||
| #[unstable(feature = "stdarch_loongarch", issue = "117427")] | ||
| pub unsafe fn frsqrte_d(a: f64) -> f64 { | ||
| __frsqrte_d(a) | ||
| } |
There was a problem hiding this comment.
looks like llvm will just optimize this (no target feature is even needed): https://godbolt.org/z/5s6hvKE51.
Overall we prefer to have fewer (manual) extern "unadjusted¨ items. Also you should probably add some tests that these instructions actually produce the instructions you expect, like so
#[cfg_attr(all(test, target_feature = "frecipe"), assert_instr(frsqrt.d))]assuming that frecipe is enabled on CI.
There was a problem hiding this comment.
looks like llvm will just optimize this (no target feature is even needed): https://godbolt.org/z/5s6hvKE51.
They're different -- frsqrte_d_manual generates frsqrt.d, not frsqrt**e**.d.
Overall we prefer to have fewer (manual)
extern "unadjusted¨items. Also you should probably add some tests that these instructions actually produce the instructions you expect, like so#[cfg_attr(all(test, target_feature = "frecipe"), assert_instr(frsqrt.d))]assuming that
frecipeis enabled on CI.
Sure, I'll add more test cases. Perhaps in a separate PR to keep things focused. Thanks!
There was a problem hiding this comment.
ah, my bad. so the "e" is for "estimate" apparently. Maybe use that word? (most functions on floats approximate the answer, but apparently this intrinsic deliberately uses less precision to achieve higher speed).
|
We will also have to add a LA32 CI run. It doesn't seem like |
|
Usually we don't run CI for T3 targets, e.g. Mips is skipped. They need to move to T2 to get to blocking CI. riscv64gc is technically T3, but that one is probably fine since it's a superset of the T2 |
| #[link_name = "llvm.loongarch.cacop.w"] | ||
| fn __cacop(a: i32, b: i32, c: i32); | ||
| #[link_name = "llvm.loongarch.csrrd.w"] | ||
| fn __csrrd(a: i32) -> i32; |
There was a problem hiding this comment.
Would it make sense to have these in the common code returning isize? It is technically a breaking change but this is still an unstable feature.
There was a problem hiding this comment.
Thanks for your comments. I don't quite understand why this is considered a breaking change. Previously, LoongArch64 exported csrrd(i32) -> i64, and it sill does. Now, LoongArch32 is introducing csrrd(i32) -> i32, which doesn't change the existing behavior.
No description provided.