<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/90025>90025</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
Running LLVM IR causes segfault on macOS aarch64 but not on x86_64
</td>
</tr>
<tr>
<th>Labels</th>
<td>
new issue
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
hameerabbasi
</td>
</tr>
</table>
<pre>
TL;DR: Identical LLVM IR produced on both platforms, only one platform consistently crashes. Seems like an ABI thing as passing values in and adding print statements shows.
Hello, I have a version of the LLVM toolchain at commit `c2a98fdeb3aede1a8db492a6ea30f4fa85b60edc` compiled on both an aarch64 and x86_64 Mac with the following commands:
```bash
cmake -G Ninja ../llvm \
-DLLVM_ENABLE_PROJECTS="mlir;llvm;clang;lld" \
-DLLVM_BUILD_EXAMPLES=ON \
-DLLVM_TARGETS_TO_BUILD="Native" \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_ASSERTIONS=ON
ninja
```
## What I've found so far
I'm attaching the full reproducer here: [reproducer.zip](https://github.com/llvm/llvm-project/files/15105804/reproducer.zip)
After running `./compile.sh`, `sddmm_opt.mlir` has the following function signature (reorganized for style):
```ll
llvm.func @_mlir_ciface_sddmm_kernel(
%arg0: !llvm.ptr, // to output struct holding memref<?x?xi64>, memref<?x?xf64>, memref<?x?xf64>, type of %arg6
%arg1: !llvm.ptr, // to memref<?x?xf64>
%arg2: !llvm.ptr, // to memref<?x?xf64>
%arg3: !llvm.ptr, // to memref<?xi64>
%arg4: !llvm.ptr, // to memref<?xi64>
%arg5: !llvm.ptr, // to memref<?xf64>
%arg6: !llvm.struct<(array<2 x i64>, array<3 x i64>)>) attributes {llvm.emit_c_interface} {
...
}
```
By reading the generated function definition after adding some sparse_tensor.print ops to the original file and linking with the right `*.o` files, I found that on aarch64, the last argument, `%arg6` isn’t getting passed in properly, it seems to have some garbage values. Since this contains some loop endpoints, it, of course, segfaults.
Changing to a simpler kernel that just prints and returns a `%args` in `sddmm.mlir` reveals that the last field contained in `%arg0` with the same type as `%arg6` reveals that returning isn’t an issue – It copies the right values over, so passing the struct into MLIR is somehow borked.
So, looking at the part of the code defining the input struct corresponding to `%arg6`, we see:
```c++
struct Shapes {
intptr_t sizes[2];
intptr_t lengths[3];
};
```
which contains no pointers or “shared” data, so that shouldn’t be an issue either.
Digging deeper, it seems the `sddmm_opt.ll` file generated is identical across both machines, and contains nothing platform-specific other than the alignment (8 bytes for both systems). Here is the LLVM generated function signature:
```ll
define void @_mlir_ciface_sddmm_kernel(ptr %0, ptr %1, ptr %2, ptr %3, ptr %4, ptr %5, { [2 x i64], [3 x i64] } %6) {
...
}
```
## To run the repoducer
To reproduce, out of the full set of files (included for posterity), you only need three files besides your LLVM build:
1. `compile.sh`
2. `sddmm.mlir`
3. Either `sddmm_test.cpp` or `sddmm_test.py`
Just edit the paths (line 6 of `compile.sh` and line 121 of `sddmm_test.py`) and run either `./a.out` or `python sddmm_test.py`.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJysV0lz27gS_jXQpSssCpRk6aCDNs94nrOU7bedVCDZJJGAAAsA7Si__lUD1GLFyWTqTZWjgFgavX5fQzgna424ZNM1m25HoveNsctGtIhW5LlwcpSb8rB8umfZevvAshXclai9LISC-_t_vYe7B-isKfsCSzAacuMb6JTwlbGtY3wDRqsDGI2nWSiMdtJ51F4doLDCNegSeERsHSj5BUFoWK3vwDdS1yAcdKSnruFZqB4dSA1ClyDKkiY7K7UH54XHFrV34Brz4hKWblm6ir-_o1KGdLmDRjwjCHhG66TRYCrwDUZLvDGqaARJ91CYtpUe2CwtuFjMqxLzTGCJYzEv88mCixmKLK0mlZhP81mKZcFmKZ3qpLrwhNAghC2a2SSo_HU-288m8F4U8CJ9E-6ujFLmhSyhO4UuHctWl9qzWRr_cuGaOFW04gvCu9_gg9SfBSQJ47dKPbfAppu4AwDebcms_e7Dan2_2396-PjHbvP0yLIt47xV0rJsTWdYti6U0HX4LBnnbwlZ__Pufrvf_Wf1_tP9jmR8_PDWtqfVw2-7p8f908d4Il72QXj5jN9L3rxf_WM3iH7676cdy7YPqFA4_Ikdq8fH3cPT3ccPUYu4S5Mbrrz1yoU8YzyDfzfCwx3jN8_k9l6X4AxUwsZNtNCC8F4UIfFCcHqlwOKQ4RYatEhFwKbr82zyTXZsumV83njfhfDxW8Zva-mbPk8K0w7hGf5711nzGQvP-G0lFTrGb8fTcTqdpxPGb6_k8sWlIavKowXba00asllKkR-yLnENmc03NO_Ksm33pvNJCPUshUa4q3yrel14qgICAeF7i8D43KKxtdDyG5ZQGQvOHxSSGj_ISqXiBFmWkEhgk3RPt-4LWYkC91GXL2g1Ksbnp8AC41Nh6zQ4lI-DgM7bYEFwIHgDpvddT_Vt-8JDY1Qo-hZbixXLNiy7_Ur_5GzCsh0d_W6p-pUlf-iQ0CCqNLvWcfxTHX8k90oI_zuEZL8uRL4pYPL_Cpj-uoC3TZhdCoiBpf18LqwVB5ZtOHyFc0CPs9nF7CL-UrVamfceHbCbAGcJttLvi73UHi2lH7vZ0tpRiSQ5UsPN9ieIsT6ARVEecaBGjVZ4Kolj0ZRYSS3DUISqHPjImRbBdcI63HvUztgkUpTpHDmIxBkra6mFAqr_wAxK6i90-kQLVtZN4B_GV4mhAh6wglgsgpcnODMnhglp3CAo4TwIW_dEhwMcHB0_S0E6zXaczVO2WHio0fvAosI5LIlaO2s6tOpAJ6UHF2jZm8icwbha2FzUONBxAo9SF0hs7YjavZDaxY3KmA5Ql52R2rsoMLQEFRSmtw7pw2FdiV7515S9aYSug_cNCHCy7RRaiBgSDf_cOx_J3wUPWvS91Q7E2V4X7NUnPDxhocVnFMpFQSefVRJVeTQhOuMkivLjHBwnWoyQIdyVe1-JjjqRGa-9LjRI53qE41wGd9RzdBLdRfSHfsc8YygyZ06dUFAiQqLU3sD7-7sHkNHtjXmB3NgvWL7y6GPogJQxIc8Guzth_bEJKkyJQ1YPN0h9Ab2FsRZdZ3Q5hOWV3ST7BSlbfsQTBeNr-guzg8zHRnSxdI_lKbXvvN17cPIbOjZdc2LW7Pt1hbr2De3ILndQVZ_GbxX2SyOL5pyn2kDITrQOjD3FY-MaYbE8fm6hFF4MMQiRdY3pVXkZ0xzPYUXpG7Sv3L-VdcjnErGL4TwXV4OvKVupY71fAI90IE-ttyiscS72mG3oVyI0UCFc2BY76GPj_c51WMhKFmBIPTJEh8uFkrUmtCD-n0N-IDwl7g_y3cF5pF5-kcDvaJE0OTXNbwDjqZv4s44h5BrCs5Hln_UMnbdEHiHNhvH4YswvxtnFeHIxngYovFlT73YkGGraNjSRnSYg8AWfzohe_jpvDJ3mk6EmLZYydrGdixto5djhBSzsTwUYmk2H4TuAPYVD6kL15dCLdcZ5tNIfiAH5Bg6mj-8rjUh8YBGHkzk6WaKjHTZGKu-lKk8hGSfhbXPZOUJc4cl3eBkXsgR2Ia_PyerR-aToOjptrue7w5Vv_iDExlIeocc3wUJFSTALzde1RgMzIoz5eNjw3QXUBRD893oou2NbLBLT-7Nm3cE3lJ1X55NRuczKRbYQI1yOb8aTNEunMz5qlgsuxkU2r4oiL7LJuJqX42q6yMbZIsPpzU0xkkue8kk64dP0JpulPKkWVV4usBSTyXyWpWM2SbEVUiWhMTG2HgV4WC7SlE9HSuSoXHh6c67xJWIH44R4I7sML4W8rx2bpEo6785SvPQKlw_DK-D4DC9E79Cd-JQ6g1YUHx9PL9C894QJtBAfoqPequVffrMENenREsz4XwAAAP__rjYFdg">