[LoongArch][LASX] Fix fptosi/fptoui from <4 x float> to <4 x i64> - #214621
Conversation
These were lowered through a 128-bit f32 to i32/u32 conversion followed by a sign/zero extension, which silently clamps any finite input that does not fit in i32/u32 instead of producing the correct 64-bit integer. Convert directly with xvftintrzl.l.s for the signed case. For the unsigned case there is no f32 -> u64 lane conversion in LASX, so widen to f64 first (which is exact) and convert with xvftintrz.lu.d. Both forms use xvpermi.d to move the inputs into the low 64 bits of each 128-bit lane, as required by these lane-wise conversions. Fixes llvm#214605
|
Hello @wszqkzqk 👋 Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.
Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description. Frequently asked questionsHow do I add reviewers? This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically. You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using What if there are no comments? If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers. Are any special GitHub settings required to contribute to LLVM? We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details. If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse. Thank you, |
|
@llvm/pr-subscribers-backend-loongarch Author: wszqkzqk (wszqkzqk) ChangesThese were lowered through a 128-bit f32 to i32/u32 conversion followed by a sign/zero extension, which silently clamps any finite input that does not fit in i32/u32 instead of producing the correct 64-bit integer. Convert directly with xvftintrzl.l.s for the signed case. For the unsigned case there is no f32 -> u64 lane conversion in LASX, so widen to f64 first (which is exact) and convert with xvftintrz.lu.d. Both forms use xvpermi.d to move the inputs into the low 64 bits of each 128-bit lane, as required by these lane-wise conversions. Fixes #214605 Full diff: https://github.com/llvm/llvm-project/pull/214621.diff 3 Files Affected:
diff --git a/llvm/lib/Target/LoongArch/LoongArchLASXInstrInfo.td b/llvm/lib/Target/LoongArch/LoongArchLASXInstrInfo.td
index e75bfc690fe53..a1d1e96fca790 100644
--- a/llvm/lib/Target/LoongArch/LoongArchLASXInstrInfo.td
+++ b/llvm/lib/Target/LoongArch/LoongArchLASXInstrInfo.td
@@ -2165,9 +2165,9 @@ def : Pat<(v8f32 (loongarch_vffint_s_l (v4i64 LASX256:$xj), (v4i64 LASX256:$xk))
// XVFTINTRZ_{W_S/L_D}
def : Pat<(v8i32 (fp_to_sint v8f32:$vj)), (XVFTINTRZ_W_S v8f32:$vj)>;
def : Pat<(v4i64 (fp_to_sint v4f64:$vj)), (XVFTINTRZ_L_D v4f64:$vj)>;
-def : Pat<(v4i64(fp_to_sint v4f32:$vj)), (VEXT2XV_D_W(SUBREG_TO_REG
- (VFTINTRZ_W_S v4f32:$vj),
- sub_128))>;
+def : Pat<(v4i64 (fp_to_sint v4f32:$vj)),
+ (XVFTINTRZL_L_S
+ (XVPERMI_D (SUBREG_TO_REG v4f32:$vj, sub_128), 216))>;
def : Pat<(v4i32(fp_to_sint v4f64:$vj)),
(EXTRACT_SUBREG(XVPICKEV_W(XVPERMI_D(XVFTINTRZ_L_D v4f64:$vj), 238),
(XVFTINTRZ_L_D v4f64:$vj)),
@@ -2176,9 +2176,10 @@ def : Pat<(v4i32(fp_to_sint v4f64:$vj)),
// XVFTINTRZ_{W_SU/L_DU}
def : Pat<(v8i32 (fp_to_uint v8f32:$vj)), (XVFTINTRZ_WU_S v8f32:$vj)>;
def : Pat<(v4i64 (fp_to_uint v4f64:$vj)), (XVFTINTRZ_LU_D v4f64:$vj)>;
-def : Pat<(v4i64(fp_to_uint v4f32:$vj)), (VEXT2XV_DU_WU(SUBREG_TO_REG
- (VFTINTRZ_WU_S v4f32:$vj),
- sub_128))>;
+def : Pat<(v4i64 (fp_to_uint v4f32:$vj)),
+ (XVFTINTRZ_LU_D
+ (XVFCVTL_D_S
+ (XVPERMI_D (SUBREG_TO_REG v4f32:$vj, sub_128), 216)))>;
def : Pat<(v4i32(fp_to_uint v4f64:$vj)),
(EXTRACT_SUBREG(XVPICKEV_W(XVPERMI_D(XVFTINTRZ_LU_D v4f64:$vj), 238),
(XVFTINTRZ_LU_D v4f64:$vj)),
diff --git a/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptosi.ll b/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptosi.ll
index a7829eb7215d8..3ce79b79877b1 100644
--- a/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptosi.ll
+++ b/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptosi.ll
@@ -61,8 +61,8 @@ define void @fptosi_v4f32_v4i64(ptr %res, ptr %in){
; CHECK-LABEL: fptosi_v4f32_v4i64:
; CHECK: # %bb.0:
; CHECK-NEXT: vld $vr0, $a1, 0
-; CHECK-NEXT: vftintrz.w.s $vr0, $vr0
-; CHECK-NEXT: vext2xv.d.w $xr0, $xr0
+; CHECK-NEXT: xvpermi.d $xr0, $xr0, 216
+; CHECK-NEXT: xvftintrzl.l.s $xr0, $xr0
; CHECK-NEXT: xvst $xr0, $a0, 0
; CHECK-NEXT: ret
%v0 = load <4 x float>, ptr %in
diff --git a/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptoui.ll b/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptoui.ll
index 2ef774d93a619..53cdcbe927f6e 100644
--- a/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptoui.ll
+++ b/llvm/test/CodeGen/LoongArch/lasx/ir-instruction/fptoui.ll
@@ -67,8 +67,9 @@ define void @fptoui_v4f32_v4i64(ptr %res, ptr %in){
; CHECK-LABEL: fptoui_v4f32_v4i64:
; CHECK: # %bb.0:
; CHECK-NEXT: vld $vr0, $a1, 0
-; CHECK-NEXT: vftintrz.wu.s $vr0, $vr0
-; CHECK-NEXT: vext2xv.du.wu $xr0, $xr0
+; CHECK-NEXT: xvpermi.d $xr0, $xr0, 216
+; CHECK-NEXT: xvfcvtl.d.s $xr0, $xr0
+; CHECK-NEXT: xvftintrz.lu.d $xr0, $xr0
; CHECK-NEXT: xvst $xr0, $a0, 0
; CHECK-NEXT: ret
%v0 = load <4 x float>, ptr %in
|
* Fix <4 x float> to <4 x i64> conversion * See also: llvm/llvm-project#214621 Signed-off-by: Zhou Qiankang <wszqkzqk@qq.com>
wangleiat
left a comment
wangleiat
left a comment
There was a problem hiding this comment.
LGTM.
Thanks for the fix.
|
LGTM |
|
@wszqkzqk Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR. Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues. How to do this, and the rest of the post-merge process, is covered in detail here. If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! |
|
/cherry-pick 29d7bae |
|
/pull-request #215165 |
…vm#214621) These were lowered through a 128-bit f32 to i32/u32 conversion followed by a sign/zero extension, which silently clamps any finite input that does not fit in i32/u32 instead of producing the correct 64-bit integer. Convert directly with xvftintrzl.l.s for the signed case. For the unsigned case there is no f32 -> u64 lane conversion in LASX, so widen to f64 first (which is exact) and convert with xvftintrz.lu.d. Both forms use xvpermi.d to move the inputs into the low 64 bits of each 128-bit lane, as required by these lane-wise conversions. Built and verified on Arch Linux for Loong64: lcpu-club/loongarch-packages#974. Both the LLVM side and the Highway test suite that discovered the bug have passed verification. Assisted by Kimi K3 AI agent. Fixes llvm#214605 (cherry picked from commit 29d7bae)
…14621) These were lowered through a 128-bit f32 to i32/u32 conversion followed by a sign/zero extension, which silently clamps any finite input that does not fit in i32/u32 instead of producing the correct 64-bit integer. Convert directly with xvftintrzl.l.s for the signed case. For the unsigned case there is no f32 -> u64 lane conversion in LASX, so widen to f64 first (which is exact) and convert with xvftintrz.lu.d. Both forms use xvpermi.d to move the inputs into the low 64 bits of each 128-bit lane, as required by these lane-wise conversions. Built and verified on Arch Linux for Loong64: lcpu-club/loongarch-packages#974. Both the LLVM side and the Highway test suite that discovered the bug have passed verification. Assisted by Kimi K3 AI agent. Fixes #214605
…vm#214621) These were lowered through a 128-bit f32 to i32/u32 conversion followed by a sign/zero extension, which silently clamps any finite input that does not fit in i32/u32 instead of producing the correct 64-bit integer. Convert directly with xvftintrzl.l.s for the signed case. For the unsigned case there is no f32 -> u64 lane conversion in LASX, so widen to f64 first (which is exact) and convert with xvftintrz.lu.d. Both forms use xvpermi.d to move the inputs into the low 64 bits of each 128-bit lane, as required by these lane-wise conversions. Built and verified on Arch Linux for Loong64: lcpu-club/loongarch-packages#974. Both the LLVM side and the Highway test suite that discovered the bug have passed verification. Assisted by Kimi K3 AI agent. Fixes llvm#214605
4 participants
These were lowered through a 128-bit f32 to i32/u32 conversion followed by a sign/zero extension, which silently clamps any finite input that does not fit in i32/u32 instead of producing the correct 64-bit integer.
Convert directly with xvftintrzl.l.s for the signed case. For the unsigned case there is no f32 -> u64 lane conversion in LASX, so widen to f64 first (which is exact) and convert with xvftintrz.lu.d. Both forms use xvpermi.d to move the inputs into the low 64 bits of each 128-bit lane, as required by these lane-wise conversions.
Built and verified on Arch Linux for Loong64: lcpu-club/loongarch-packages#974. Both the LLVM side and the Highway test suite that discovered the bug have passed verification.
Assisted by Kimi K3 AI agent.
Fixes #214605