https://github.com/heiher closed https://github.com/llvm/llvm-project/pull/93814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/wangleiat approved this pull request.
Thanks.
https://github.com/llvm/llvm-project/pull/93814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
wangleiat wrote:
> @wangleiat What do you think?
I think this is a good start, and we should make i32 truly legal on
LoongArch64, just like RISC-V.
https://github.com/llvm/llvm-project/pull/93814
___
cfe-commits mailing list
https://github.com/heiher updated
https://github.com/llvm/llvm-project/pull/93814
>From 5667b2c24b6e2b277e9478152ae318c4e01d3d09 Mon Sep 17 00:00:00 2001
From: WANG Rui
Date: Wed, 22 May 2024 15:14:28 +0800
Subject: [PATCH 1/2] [LoongArch] Adjust LA64 data layout by using n32:64 in
layout
@@ -5368,8 +5368,8 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL,
StringRef TT) {
return DL.empty() ? std::string("G1") : (DL + "-G1").str();
}
- if (T.isRISCV64()) {
-// Make i32 a native type for 64-bit RISC-V.
+ if (T.isRISCV64() ||
https://github.com/SixWeining commented:
@wangleiat What do you think?
https://github.com/llvm/llvm-project/pull/93814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/SixWeining edited
https://github.com/llvm/llvm-project/pull/93814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-backend-loongarch
Author: hev (heiher)
Changes
Although i32 type is illegal in the backend, LA64 has pretty good support for
i32 types by using W instructions.
By adding n32 to the DataLayout string, middle end optimizations
https://github.com/heiher created
https://github.com/llvm/llvm-project/pull/93814
Although i32 type is illegal in the backend, LA64 has pretty good support for
i32 types by using W instructions.
By adding n32 to the DataLayout string, middle end optimizations will consider
i32 to be a native
