[MIPS] LLVM data layout give i128 an alignment of 16 for mips64 #112084

yingopq · 2024-10-12T07:19:56Z

Fix parts of #102783.

llvmbot · 2024-10-12T07:20:29Z

@llvm/pr-subscribers-llvm-ir

@llvm/pr-subscribers-clang

Author: None (yingopq)

Changes

Fix parts of #102783.

Full diff: https://github.com/llvm/llvm-project/pull/112084.diff

7 Files Affected:

(modified) clang/lib/Basic/Targets/Mips.h (+2-2)
(modified) clang/test/CodeGen/target-data.c (+4-4)
(modified) llvm/lib/IR/AutoUpgrade.cpp (+1-1)
(modified) llvm/lib/Target/Mips/MipsTargetMachine.cpp (+1-1)
(added) llvm/test/CodeGen/Mips/data-layout.ll (+60)
(modified) llvm/test/CodeGen/Mips/implicit-sret.ll (+9-9)
(modified) llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp (+8)

diff --git a/clang/lib/Basic/Targets/Mips.h b/clang/lib/Basic/Targets/Mips.h
index 45425db3ac27ad..8acaf56523b218 100644
--- a/clang/lib/Basic/Targets/Mips.h
+++ b/clang/lib/Basic/Targets/Mips.h
@@ -28,9 +28,9 @@ class LLVM_LIBRARY_VISIBILITY MipsTargetInfo : public TargetInfo {
     if (ABI == "o32")
       Layout = "m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64";
     else if (ABI == "n32")
-      Layout = "m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128";
+      Layout = "m:e-p:32:32-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128";
     else if (ABI == "n64")
-      Layout = "m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128";
+      Layout = "m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128";
     else
       llvm_unreachable("Invalid ABI");
 
diff --git a/clang/test/CodeGen/target-data.c b/clang/test/CodeGen/target-data.c
index 8548aa00cfe877..054825011dd36c 100644
--- a/clang/test/CodeGen/target-data.c
+++ b/clang/test/CodeGen/target-data.c
@@ -54,7 +54,7 @@
 // RUN: FileCheck %s -check-prefix=MIPS-64EL
 // RUN: %clang_cc1 -triple mipsisa64r6el-linux-gnuabi64 -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=MIPS-64EL
-// MIPS-64EL: target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EL: target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 
 // RUN: %clang_cc1 -triple mips64el-linux-gnu -o - -emit-llvm -target-abi n32 \
 // RUN: %s | FileCheck %s -check-prefix=MIPS-64EL-N32
@@ -64,7 +64,7 @@
 // RUN: %s | FileCheck %s -check-prefix=MIPS-64EL-N32
 // RUN: %clang_cc1 -triple mipsisa64r6el-linux-gnuabin32 -o - -emit-llvm \
 // RUN: %s | FileCheck %s -check-prefix=MIPS-64EL-N32
-// MIPS-64EL-N32: target datalayout = "e-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EL-N32: target datalayout = "e-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 
 // RUN: %clang_cc1 -triple mips64-linux-gnu -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=MIPS-64EB
@@ -74,7 +74,7 @@
 // RUN: FileCheck %s -check-prefix=MIPS-64EB
 // RUN: %clang_cc1 -triple mipsisa64r6-linux-gnuabi64 -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=MIPS-64EB
-// MIPS-64EB: target datalayout = "E-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EB: target datalayout = "E-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 
 // RUN: %clang_cc1 -triple mips64-linux-gnu -o - -emit-llvm %s -target-abi n32 \
 // RUN: | FileCheck %s -check-prefix=MIPS-64EB-N32
@@ -84,7 +84,7 @@
 // RUN: | FileCheck %s -check-prefix=MIPS-64EB-N32
 // RUN: %clang_cc1 -triple mipsisa64r6-linux-gnuabin32 -o - -emit-llvm %s \
 // RUN: | FileCheck %s -check-prefix=MIPS-64EB-N32
-// MIPS-64EB-N32: target datalayout = "E-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32:64-S128"
+// MIPS-64EB-N32: target datalayout = "E-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 
 // RUN: %clang_cc1 -triple powerpc64-lv2 -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PS3
diff --git a/llvm/lib/IR/AutoUpgrade.cpp b/llvm/lib/IR/AutoUpgrade.cpp
index 3753509f9aa718..95e011b5aa1b9a 100644
--- a/llvm/lib/IR/AutoUpgrade.cpp
+++ b/llvm/lib/IR/AutoUpgrade.cpp
@@ -5566,7 +5566,7 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL, StringRef TT) {
     return Res;
   }
 
-  if (T.isSPARC()) {
+  if (T.isSPARC() || T.isMIPS64()) {
     // Add "-i128:128"
     std::string I64 = "-i64:64";
     std::string I128 = "-i128:128";
diff --git a/llvm/lib/Target/Mips/MipsTargetMachine.cpp b/llvm/lib/Target/Mips/MipsTargetMachine.cpp
index 7802767e31c2f6..0554d275d1e0b3 100644
--- a/llvm/lib/Target/Mips/MipsTargetMachine.cpp
+++ b/llvm/lib/Target/Mips/MipsTargetMachine.cpp
@@ -99,7 +99,7 @@ static std::string computeDataLayout(const Triple &TT, StringRef CPU,
   // aligned. On N64 64 bit registers are also available and the stack is
   // 128 bit aligned.
   if (ABI.IsN64() || ABI.IsN32())
-    Ret += "-n32:64-S128";
+    Ret += "-i128:128-n32:64-S128";
   else
     Ret += "-n32-S64";
 
diff --git a/llvm/test/CodeGen/Mips/data-layout.ll b/llvm/test/CodeGen/Mips/data-layout.ll
new file mode 100644
index 00000000000000..0b2fc213bb0b60
--- /dev/null
+++ b/llvm/test/CodeGen/Mips/data-layout.ll
@@ -0,0 +1,60 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
+; RUN: llc -mtriple=mips64-linux-gnuabi64 -mcpu=mips64 < %s | FileCheck %s -check-prefix=MIPS64
+; RUN: llc -mtriple=mips64el-linux-gnuabi64 -mcpu=mips64 < %s | FileCheck %s -check-prefix=MIPS64EL
+
+; MIPS64:      .p2align 2, 0x0
+; MIPS64-NEXT: Li8:
+; MIPS64-NEXT: .byte 10 # 0xa
+; MIPS64-NEXT: .size .Li8, 1
+
+; MIPS64EL:      .p2align 2, 0x0
+; MIPS64EL-NEXT: Li8:
+; MIPS64EL-NEXT: .byte 10 # 0xa
+; MIPS64EL-NEXT: .size .Li8, 1
+@i8 = private constant i8 10
+
+; MIPS64:      .p2align 2, 0x0
+; MIPS64-NEXT: .Li16:
+; MIPS64-NEXT: .2byte 10 # 0xa
+; MIPS64-NEXT:  .size .Li16, 2
+
+; MIPS64EL:      .p2align 2, 0x0
+; MIPS64EL-NEXT: .Li16:
+; MIPS64EL-NEXT: .2byte 10 # 0xa
+; MIPS64EL-NEXT:  .size .Li16, 2
+@i16 = private constant i16 10
+
+; MIPS64:      .p2align 2, 0x0
+; MIPS64-NEXT: .Li32:
+; MIPS64-NEXT: .4byte 10 # 0xa
+; MIPS64-NEXT: .size .Li32, 4
+
+; MIPS64EL:      .p2align 2, 0x0
+; MIPS64EL-NEXT: .Li32:
+; MIPS64EL-NEXT: .4byte 10 # 0xa
+; MIPS64EL-NEXT: .size .Li32, 4
+@i32 = private constant i32 10
+
+; MIPS64:      .p2align 3, 0x0
+; MIPS64-NEXT: .Li64:
+; MIPS64-NEXT: .8byte 10 # 0xa
+; MIPS64-NEXT:  .size .Li64, 8
+
+; MIPS64EL:      .p2align 3, 0x0
+; MIPS64EL-NEXT: .Li64:
+; MIPS64EL-NEXT: .8byte 10 # 0xa
+; MIPS64EL-NEXT:  .size .Li64, 8
+@i64 = private constant i64 10
+
+; MIPS64:      .p2align 4, 0x0
+; MIPS64-NEXT: .Li128:
+; MIPS64-NEXT: .8byte 0
+; MIPS64-NEXT: .8byte 10
+; MIPS64-NEXT:  .size .Li128, 16
+
+; MIPS64EL:      .p2align 4, 0x0
+; MIPS64EL-NEXT: .Li128:
+; MIPS64EL-NEXT: .8byte 10
+; MIPS64EL-NEXT: .8byte 0
+; MIPS64EL-NEXT:  .size .Li128, 16
+@i128 = private constant i128 10
diff --git a/llvm/test/CodeGen/Mips/implicit-sret.ll b/llvm/test/CodeGen/Mips/implicit-sret.ll
index 9c4d28fa0e4718..c8400abacaf8c6 100644
--- a/llvm/test/CodeGen/Mips/implicit-sret.ll
+++ b/llvm/test/CodeGen/Mips/implicit-sret.ll
@@ -11,21 +11,21 @@ declare dso_local { i32, i128, i64 } @implicit_sret_decl() unnamed_addr
 define internal void @test() unnamed_addr nounwind {
 ; CHECK-LABEL: test:
 ; CHECK:       # %bb.0: # %start
-; CHECK-NEXT:    daddiu $sp, $sp, -48
-; CHECK-NEXT:    sd $ra, 40($sp) # 8-byte Folded Spill
-; CHECK-NEXT:    daddiu $4, $sp, 8
+; CHECK-NEXT:    daddiu $sp, $sp, -64
+; CHECK-NEXT:    sd $ra, 56($sp) # 8-byte Folded Spill
+; CHECK-NEXT:    daddiu $4, $sp, 0
 ; CHECK-NEXT:    jal implicit_sret_decl
 ; CHECK-NEXT:    nop
 ; CHECK-NEXT:    ld $6, 24($sp)
 ; CHECK-NEXT:    ld $5, 16($sp)
 ; CHECK-NEXT:    ld $7, 32($sp)
-; CHECK-NEXT:    lw $1, 8($sp)
+; CHECK-NEXT:    lw $1, 0($sp)
 ; CHECK-NEXT:    # implicit-def: $a0_64
 ; CHECK-NEXT:    move $4, $1
 ; CHECK-NEXT:    jal use_sret
 ; CHECK-NEXT:    nop
-; CHECK-NEXT:    ld $ra, 40($sp) # 8-byte Folded Reload
-; CHECK-NEXT:    daddiu $sp, $sp, 48
+; CHECK-NEXT:    ld $ra, 56($sp) # 8-byte Folded Reload
+; CHECK-NEXT:    daddiu $sp, $sp, 64
 ; CHECK-NEXT:    jr $ra
 ; CHECK-NEXT:    nop
 start:
@@ -42,11 +42,11 @@ define internal { i32, i128, i64 } @implicit_sret_impl() unnamed_addr nounwind {
 ; CHECK:       # %bb.0:
 ; CHECK-NEXT:    # kill: def $at_64 killed $a0_64
 ; CHECK-NEXT:    daddiu $1, $zero, 20
-; CHECK-NEXT:    sd $1, 16($4)
+; CHECK-NEXT:    sd $1, 24($4)
 ; CHECK-NEXT:    daddiu $1, $zero, 0
-; CHECK-NEXT:    sd $zero, 8($4)
+; CHECK-NEXT:    sd $zero, 16($4)
 ; CHECK-NEXT:    daddiu $1, $zero, 30
-; CHECK-NEXT:    sd $1, 24($4)
+; CHECK-NEXT:    sd $1, 32($4)
 ; CHECK-NEXT:    addiu $1, $zero, 10
 ; CHECK-NEXT:    sw $1, 0($4)
 ; CHECK-NEXT:    jr $ra
diff --git a/llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp b/llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp
index 1cd4a47c75739b..88c680b6c499eb 100644
--- a/llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp
+++ b/llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp
@@ -75,6 +75,14 @@ TEST(DataLayoutUpgradeTest, ValidDataLayoutUpgrade) {
   EXPECT_EQ(UpgradeDataLayoutString("E-m:e-i64:64-n32:64-S128", "sparcv9"),
             "E-m:e-i64:64-i128:128-n32:64-S128");
 
+  // Check that SPARC targets add -i128:128.
+  EXPECT_EQ(UpgradeDataLayoutString(
+                "E-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128", "mips64"),
+            "E-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128");
+  EXPECT_EQ(UpgradeDataLayoutString(
+                "e-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128", "mips64el"),
+            "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128");
+
   // Check that SPIR && SPIRV targets add -G1 if it's not present.
   EXPECT_EQ(UpgradeDataLayoutString("e-p:32:32", "spir"), "e-p:32:32-G1");
   EXPECT_EQ(UpgradeDataLayoutString("e-p:32:32", "spir64"), "e-p:32:32-G1");

llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp

nikic

This looks technically fine, but I'm having trouble finding a normative reference for this. Is there an ABI specification for N32/N64 somewhere?

Also, what alignment does clang use for o32 with ForceEnableInt128?

llvm-project/clang/lib/Basic/Targets/Mips.h

Line 441 in cb2f161

return (ABI == "n32" || ABI == "n64") || getTargetOpts().ForceEnableInt128;

Possibly we need to specify the alignment in that case as well to cover that option.

beetrees · 2024-10-15T23:50:48Z

Clang currently always gives __int128 and __uint128 an alignment of 16 bytes (128 bits), except on SystemZ where they have an alignment of 8 bytes (64 bits).

I'm not aware of any MIPS ABI specification that includes 128-bit integers, but an alignment of 16 bytes is used by both Clang and GCC, so it appears to be the de facto standard. (While the Linux Foundation has a copy of the o32 System V ABI, the closest thing I could find for n32 and n64 are various copies of "MIPSpro™ N32 ABI Handbook" and "MIPSpro™ 64-Bit Porting and Transition Guide".)

yingopq · 2024-10-16T01:54:39Z

This looks technically fine, but I'm having trouble finding a normative reference for this. Is there an ABI specification for N32/N64 somewhere?

Also, what alignment does clang use for o32 with ForceEnableInt128?

llvm-project/clang/lib/Basic/Targets/Mips.h

Line 441 in cb2f161

return (ABI == "n32" || ABI == "n64") || getTargetOpts().ForceEnableInt128;

Possibly we need to specify the alignment in that case as well to cover that option.

I did not find any ABI specification for N32/N64 about i128 alignment, and I am doing research about the ForceEnableInt128.

yingopq · 2024-10-16T03:03:27Z

Also, what alignment does clang use for o32 with ForceEnableInt128

I did test about o32 with ForceEnableInt128:

$ cat 1.c
#include <stdio.h>

int main()
{
    printf("alignment of int128: %zd\n", _Alignof(__int128));
    return 0;
}

$ sudo ./build/bin/clang -target mipsel-unknown-linux-gnu -fforce-enable-int128 -emit-llvm -S 1.c
$ sudo ./build/bin/llc -march=mipsel -target-abi o32 -relocation-model=pic 1.ll
$ sudo ./build/bin/clang -target mipsel-unknown-linux-gnu -fPIC -pthread 1.s -o a1main

root@debian-sid-mipsel:~# ./a1main 
alignment of int128: 16

root@debian-sid-mipsel:~# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-linux-gnu/12/lto-wrapper
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=mipsel-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all --with-arch-64=mips64r2 --enable-checking=release --build=mipsel-linux-gnu --host=mipsel-linux-gnu --target=mipsel-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

Possibly we need to specify the alignment in that case as well to cover that option.

Thanks for your reminder, I would add this.

yingopq · 2024-10-17T09:18:06Z

This looks technically fine, but I'm having trouble finding a normative reference for this. Is there an ABI specification for N32/N64 somewhere?

Also, what alignment does clang use for o32 with ForceEnableInt128?

llvm-project/clang/lib/Basic/Targets/Mips.h

Line 441 in cb2f161

return (ABI == "n32" || ABI == "n64") || getTargetOpts().ForceEnableInt128;

Possibly we need to specify the alignment in that case as well to cover that option.

@nikic I checked several other arch-32 situations with ForceEnableInt128, and they all use alloca i128, align 16.
But they did not modify the target datalayout content with i128:128, should mips be consistent?

nikic · 2024-10-17T10:06:36Z

@nikic I checked several other arch-32 situations with ForceEnableInt128, and they all use alloca i128, align 16. But they did not modify the target datalayout content with i128:128, should mips be consistent?

I think either way is fine here. Something to consider though, is that the AutoUpgrade for the DataLayout has to match. So if you don't add i128:128 to the o32 DL, then it shouldn't get added by AutoUpgrade either.

yingopq · 2024-10-18T02:39:53Z

@nikic I checked several other arch-32 situations with ForceEnableInt128, and they all use alloca i128, align 16. But they did not modify the target datalayout content with i128:128, should mips be consistent?

I think either way is fine here. Something to consider though, is that the AutoUpgrade for the DataLayout has to match. So if you don't add i128:128 to the o32 DL, then it shouldn't get added by AutoUpgrade either.

OK, I decided to not add this.
Please help review whether there has other issue, thanks!

yingopq · 2024-10-30T02:57:44Z

Ping

brad0 · 2024-11-05T08:26:25Z

@nikic

nikic · 2024-11-05T09:13:30Z

@nikic I checked several other arch-32 situations with ForceEnableInt128, and they all use alloca i128, align 16. But they did not modify the target datalayout content with i128:128, should mips be consistent?

I think either way is fine here. Something to consider though, is that the AutoUpgrade for the DataLayout has to match. So if you don't add i128:128 to the o32 DL, then it shouldn't get added by AutoUpgrade either.

OK, I decided to not add this. Please help review whether there has other issue, thanks!

In that case we also need to prevent the auto-upgrade if the o32 ABI is used. Otherwise auto-upgrade will produce the i128:128 data layout for o32, which directly targeting it would not.

yingopq · 2024-11-06T08:58:47Z

@nikic I checked several other arch-32 situations with ForceEnableInt128, and they all use alloca i128, align 16. But they did not modify the target datalayout content with i128:128, should mips be consistent?

I think either way is fine here. Something to consider though, is that the AutoUpgrade for the DataLayout has to match. So if you don't add i128:128 to the o32 DL, then it shouldn't get added by AutoUpgrade either.

OK, I decided to not add this. Please help review whether there has other issue, thanks!

In that case we also need to prevent the auto-upgrade if the o32 ABI is used. Otherwise auto-upgrade will produce the i128:128 data layout for o32, which directly targeting it would not.

OK, I updated the AutoUpgrade.cpp.

nikic

LGTM, thanks!

nikic · 2024-11-06T09:14:18Z

llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp

+            "E-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128");
+  EXPECT_EQ(UpgradeDataLayoutString(
+                "e-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128", "mips64el"),
+            "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128");


Can you please also test the non-upgrade for the o32 DL here?

nikic · 2024-11-06T09:56:41Z

@yingopq As you regularly do MIPS work, I'd recommend to request commit access, as described at https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access.

Fix parts of llvm#102783.

LLVM changed the data layout in llvm/llvm-project#112084

Update mips64 data layout to match LLVM 20 change LLVM changed the data layout in llvm/llvm-project#112084

yingopq · 2024-11-08T02:49:56Z

@yingopq As you regularly do MIPS work, I'd recommend to request commit access, as described at https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access.

@nikic Thanks for your recommendation, I would try to request commit access.

Rollup merge of rust-lang#132741 - zmodem:mips_data_layout, r=nikic Update mips64 data layout to match LLVM 20 change LLVM changed the data layout in llvm/llvm-project#112084

yingopq · 2024-11-08T07:17:56Z

@yingopq As you regularly do MIPS work, I'd recommend to request commit access, as described at https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access.

@nikic Thanks for your recommendation, I would try to request commit access.

Hi @nikic, do I need to send an email to apply myself, or can you apply for me? Thanks!

brad0 · 2024-11-08T07:28:28Z

Hi @nikic, do I need to send an email to apply myself, or can you apply for me? Thanks!

Do as it says in the first paragraph and send the email yourself.

yingopq · 2024-11-08T07:31:46Z

Hi @nikic, do I need to send an email to apply myself, or can you apply for me? Thanks!

Do as it says in the first paragraph and send the email yourself.

OK, thanks!

llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" llvm:ir labels Oct 12, 2024

brad0 reviewed Oct 12, 2024

View reviewed changes

llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp Outdated Show resolved Hide resolved

brad0 requested a review from nikic October 12, 2024 09:29

yingopq force-pushed the Fix_bug_issue_102783 branch from 03b1e39 to 956c862 Compare October 12, 2024 09:31

nikic reviewed Oct 12, 2024

View reviewed changes

beetrees mentioned this pull request Oct 12, 2024

LLVM data layout for i128 doesn't match Clang's alignment of __int128_t on 64-bit PowerPC, 64-bit SPARC and 64-bit MIPS #102783

Open

3 tasks

brad0 requested a review from nikic November 2, 2024 02:13

yingopq force-pushed the Fix_bug_issue_102783 branch from 956c862 to fa5a485 Compare November 6, 2024 08:57

nikic approved these changes Nov 6, 2024

View reviewed changes

yingopq force-pushed the Fix_bug_issue_102783 branch 2 times, most recently from d6065cc to c33598b Compare November 6, 2024 09:42

[MIPS] LLVM data layout give i128 an alignment of 16 for mips64

c148aee

Fix parts of llvm#102783.

yingopq force-pushed the Fix_bug_issue_102783 branch from c33598b to c148aee Compare November 6, 2024 10:07

nikic merged commit 86e4beb into llvm:main Nov 6, 2024
6 of 8 checks passed

zmodem added a commit to zmodem/rust that referenced this pull request Nov 7, 2024

Update mips64 data layout to match LLVM 20 change

392ac35

LLVM changed the data layout in llvm/llvm-project#112084

zmodem mentioned this pull request Nov 7, 2024

Update mips64 data layout to match LLVM 20 change rust-lang/rust#132741

Merged

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 8, 2024

Rollup merge of rust-lang#132741 - zmodem:mips_data_layout, r=nikic

a7bae73

Update mips64 data layout to match LLVM 20 change LLVM changed the data layout in llvm/llvm-project#112084

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 8, 2024

Rollup merge of rust-lang#132741 - zmodem:mips_data_layout, r=nikic

97dbab9

Update mips64 data layout to match LLVM 20 change LLVM changed the data layout in llvm/llvm-project#112084

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[MIPS] LLVM data layout give i128 an alignment of 16 for mips64 #112084

[MIPS] LLVM data layout give i128 an alignment of 16 for mips64 #112084

yingopq commented Oct 12, 2024

llvmbot commented Oct 12, 2024 •

edited

Loading

nikic left a comment

beetrees commented Oct 15, 2024

yingopq commented Oct 16, 2024

yingopq commented Oct 16, 2024

yingopq commented Oct 17, 2024

nikic commented Oct 17, 2024

yingopq commented Oct 18, 2024

yingopq commented Oct 30, 2024

brad0 commented Nov 5, 2024

nikic commented Nov 5, 2024

yingopq commented Nov 6, 2024

nikic left a comment

nikic Nov 6, 2024

yingopq Nov 6, 2024

nikic commented Nov 6, 2024

yingopq commented Nov 8, 2024 •

edited

Loading

yingopq commented Nov 8, 2024

brad0 commented Nov 8, 2024 •

edited

Loading

yingopq commented Nov 8, 2024

[MIPS] LLVM data layout give i128 an alignment of 16 for mips64 #112084

[MIPS] LLVM data layout give i128 an alignment of 16 for mips64 #112084

Conversation

yingopq commented Oct 12, 2024

llvmbot commented Oct 12, 2024 • edited Loading

nikic left a comment

Choose a reason for hiding this comment

beetrees commented Oct 15, 2024

yingopq commented Oct 16, 2024

yingopq commented Oct 16, 2024

yingopq commented Oct 17, 2024

nikic commented Oct 17, 2024

yingopq commented Oct 18, 2024

yingopq commented Oct 30, 2024

brad0 commented Nov 5, 2024

nikic commented Nov 5, 2024

yingopq commented Nov 6, 2024

nikic left a comment

Choose a reason for hiding this comment

nikic Nov 6, 2024

Choose a reason for hiding this comment

yingopq Nov 6, 2024

Choose a reason for hiding this comment

nikic commented Nov 6, 2024

yingopq commented Nov 8, 2024 • edited Loading

yingopq commented Nov 8, 2024

brad0 commented Nov 8, 2024 • edited Loading

yingopq commented Nov 8, 2024

llvmbot commented Oct 12, 2024 •

edited

Loading

yingopq commented Nov 8, 2024 •

edited

Loading

brad0 commented Nov 8, 2024 •

edited

Loading