[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-06 Thread Xi Ruoyao via llvm-branch-commits
xry111 wrote: I have some doubt about this change. To me if the user requests `xvpermi.q` via the `loongarch_lasx_xvpermi_q` intrinsic, we should give her/him the `xvpermi.q` instruction. If (s)he is passing an invalid operand then (s)he is invoking the undefined behavior herself/himself and

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-07 Thread Lu Weining via llvm-branch-commits
SixWeining wrote: > I have some doubt about this change. > > To me if the user requests `xvpermi.q` via the `loongarch_lasx_xvpermi_q` > intrinsic, we should give her/him the `xvpermi.q` instruction. If (s)he is > passing an invalid operand then (s)he is invoking the undefined behavior > hers

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-07 Thread WÁNG Xuěruì via llvm-branch-commits
xen0n wrote: For the record, based on the principle of "explicit is better than implicit" that generally holds, I'd favor an approach where such compile-time-verifiable out-of-range operands are given compile-time errors, or we should just pass through the value unmodified. Otherwise the intri

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-10 Thread Lu Weining via llvm-branch-commits
https://github.com/SixWeining closed https://github.com/llvm/llvm-project/pull/83540 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-10 Thread Lu Weining via llvm-branch-commits
SixWeining wrote: > For the record, based on the principle of "explicit is better than implicit" > that generally holds, I'd favor an approach where such > compile-time-verifiable out-of-range operands are given compile-time errors, > or we should just pass through the value unmodified. Otherw

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-01 Thread via llvm-branch-commits
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/83540 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-01 Thread via llvm-branch-commits
https://github.com/llvmbot created https://github.com/llvm/llvm-project/pull/83540 Backport d7c80bba698bded48c1df4b4bb7424a181aa6195 Requested by: @leecheechen >From 3009ba6242d2e334b499a36d2706c0a4c004cfeb Mon Sep 17 00:00:00 2001 From: leecheechen Date: Tue, 27 Feb 2024 15:38:11 +0800 Subje

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

2024-03-01 Thread via llvm-branch-commits
llvmbot wrote: @llvm/pr-subscribers-backend-loongarch Author: None (llvmbot) Changes Backport d7c80bba698bded48c1df4b4bb7424a181aa6195 Requested by: @leecheechen --- Full diff: https://github.com/llvm/llvm-project/pull/83540.diff 2 Files Affected: - (modified) llvm/lib/Target/LoongArc