Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-enable FastISel for MIPS O32 with LLVM 20 #21215

Open
Tracked by #22014
alexrp opened this issue Aug 27, 2024 · 2 comments
Open
Tracked by #22014

Re-enable FastISel for MIPS O32 with LLVM 20 #21215

alexrp opened this issue Aug 27, 2024 · 2 comments
Assignees
Labels
arch-mips 32-bit and 64-bit MIPS backend-llvm The LLVM backend outputs an LLVM IR Module. bug Observed behavior contradicts documented or intended behavior upstream An issue with a third party project that Zig uses.
Milestone

Comments

@alexrp
Copy link
Member

alexrp commented Aug 27, 2024

Zig Version

93cb44c

Steps to Reproduce and Observed Behavior

zig build test -fqemu --glibc-runtimes <...> test-behavior -Dtest-slow-targets -Dtest-target-filter=mips-linux.4.19...6.10.3-gnueabihf.2.28

Program received signal SIGBUS, Bus error.
0x00068bd8 in mem.eqlBytes (a=..., b=...) at /home/alexrp/Source/zig/lib/std/mem.zig:685
685                 x |= @as(u32, @bitCast(a[n..][0..4].*)) ^ @as(u32, @bitCast(b[n..][0..4].*));
(gdb) bt
#0  0x00068bd8 in mem.eqlBytes (a=..., b=...) at /home/alexrp/Source/zig/lib/std/mem.zig:685
#1  0x00063748 in mem.eql__anon_1648 (a=..., b=...) at /home/alexrp/Source/zig/lib/std/mem.zig:660
#2  0x0006392c in mem.startsWith__anon_1657 (haystack=..., needle=...) at /home/alexrp/Source/zig/lib/std/mem.zig:2913
#3  0x00055f10 in test_runner.main () at /home/alexrp/Source/zig/lib/compiler/test_runner.zig:38
#4  0x00055674 in start.callMain () at /home/alexrp/Source/zig/lib/std/start.zig:605
#5  start.callMainWithArgs () at /home/alexrp/Source/zig/lib/std/start.zig:574
#6  start.main (c_argc=3, c_argv=0x2b2ab314, c_envp=0x2b2ab324) at /home/alexrp/Source/zig/lib/std/start.zig:589
(gdb) disas $pc-100,$pc+100
Dump of assembler code from 0x68b74 to 0x68c3c:
   0x00068b74 <mem.eqlBytes+2068>:      sw      at,116(s8)
   0x00068b78 <mem.eqlBytes+2072>:      lw      v1,352(s8)
   0x00068b7c <mem.eqlBytes+2076>:      addu    v1,v1,v0
   0x00068b80 <mem.eqlBytes+2080>:      sw      v1,120(s8)
   0x00068b84 <mem.eqlBytes+2084>:      li      v1,4
   0x00068b88 <mem.eqlBytes+2088>:      addu    v0,v0,v1
   0x00068b8c <mem.eqlBytes+2092>:      sw      v0,124(s8)
   0x00068b90 <mem.eqlBytes+2096>:      sltu    at,at,v0
   0x00068b94 <mem.eqlBytes+2100>:      xori    at,at,0x1
   0x00068b98 <mem.eqlBytes+2104>:      bgtz    at,0x68bf0 <mem.eqlBytes+2192>
   0x00068b9c <mem.eqlBytes+2108>:      nop
   0x00068ba0 <mem.eqlBytes+2112>:      b       0x68bf8 <mem.eqlBytes+2200>
   0x00068ba4 <mem.eqlBytes+2116>:      nop
   0x00068ba8 <mem.eqlBytes+2120>:      b       0x68b4c <mem.eqlBytes+2028>
   0x00068bac <mem.eqlBytes+2124>:      nop
   0x00068bb0 <mem.eqlBytes+2128>:      lw      a1,136(s8)
   0x00068bb4 <mem.eqlBytes+2132>:      lw      a0,144(s8)
   0x00068bb8 <mem.eqlBytes+2136>:      lw      at,220(s8)
   0x00068bbc <mem.eqlBytes+2140>:      lw      at,-32728(at)
   0x00068bc0 <mem.eqlBytes+2144>:      addiu   t9,at,22496
   0x00068bc4 <mem.eqlBytes+2148>:      bal     0x557e0 <builtin.panicOutOfBounds>
   0x00068bc8 <mem.eqlBytes+2152>:      nop
   0x00068bcc <mem.eqlBytes+2156>:      lw      at,132(s8)
   0x00068bd0 <mem.eqlBytes+2160>:      lw      v0,112(s8)
   0x00068bd4 <mem.eqlBytes+2164>:      lw      v1,120(s8)
=> 0x00068bd8 <mem.eqlBytes+2168>:      lw      v1,0(v1)
   0x00068bdc <mem.eqlBytes+2172>:      xor     v0,v0,v1
   0x00068be0 <mem.eqlBytes+2176>:      or      at,at,v0
   0x00068be4 <mem.eqlBytes+2180>:      sw      at,320(s8)
   0x00068be8 <mem.eqlBytes+2184>:      b       0x68ac0 <mem.eqlBytes+1888>
   0x00068bec <mem.eqlBytes+2188>:      nop
   0x00068bf0 <mem.eqlBytes+2192>:      b       0x68bcc <mem.eqlBytes+2156>
   0x00068bf4 <mem.eqlBytes+2196>:      nop
   0x00068bf8 <mem.eqlBytes+2200>:      lw      a1,116(s8)
   0x00068bfc <mem.eqlBytes+2204>:      lw      a0,124(s8)
   0x00068c00 <mem.eqlBytes+2208>:      lw      at,220(s8)
   0x00068c04 <mem.eqlBytes+2212>:      lw      at,-32728(at)
   0x00068c08 <mem.eqlBytes+2216>:      addiu   t9,at,22496
   0x00068c0c <mem.eqlBytes+2220>:      bal     0x557e0 <builtin.panicOutOfBounds>
   0x00068c10 <mem.eqlBytes+2224>:      nop
   0x00068c14 <mem.eqlBytes+2228>:      li      at,2
   0x00068c18 <mem.eqlBytes+2232>:      sw      at,268(s8)
   0x00068c1c <mem.eqlBytes+2236>:      li      at,3
   0x00068c20 <mem.eqlBytes+2240>:      sw      at,272(s8)
   0x00068c24 <mem.eqlBytes+2244>:      li      at,4
   0x00068c28 <mem.eqlBytes+2248>:      sw      at,276(s8)
   0x00068c2c <mem.eqlBytes+2252>:      li      at,5
   0x00068c30 <mem.eqlBytes+2256>:      sw      at,280(s8)
   0x00068c34 <mem.eqlBytes+2260>:      lw      at,224(s8)
   0x00068c38 <mem.eqlBytes+2264>:      li      v0,0
End of assembler dump.

It looks like an LLVM miscompilation, but not sure yet.

Very oddly, -musleabihf is fine (but note that I haven't upstreamed my branch for that yet).

Expected Behavior

No failure.

@alexrp alexrp added the bug Observed behavior contradicts documented or intended behavior label Aug 27, 2024
@Vexu Vexu added upstream An issue with a third party project that Zig uses. arch-mips 32-bit and 64-bit MIPS backend-llvm The LLVM backend outputs an LLVM IR Module. labels Aug 27, 2024
@Vexu Vexu added this to the 1.0.0 milestone Aug 27, 2024
@alexrp
Copy link
Member Author

alexrp commented Aug 27, 2024

llvm/llvm-project#106231

@alexrp alexrp changed the title All mips(el)-linux-gnueabihf tests crash in std.mem.eqlBytes() All mips(el)-linux-gnueabi* tests crash in std.mem.eqlBytes() Aug 28, 2024
alexrp added a commit to alexrp/zig that referenced this issue Aug 28, 2024
alexrp added a commit to alexrp/zig that referenced this issue Aug 28, 2024
@alexrp
Copy link
Member Author

alexrp commented Sep 7, 2024

Workaround added in #21224; this issue now tracks removing the workaround with LLVM 20.

wzssyqa pushed a commit to llvm/llvm-project that referenced this issue Sep 12, 2024
We encountered this problem in Zig, causing all of our
`mips(el)-linux-gnueabi*` tests to fail:
ziglang/zig#21215

For these unusual cases, let's just bail in `MipsFastISel` since
`MipsTargetLowering` can handle them fine.

Note: I don't have commit access.
@alexrp alexrp changed the title All mips(el)-linux-gnueabi* tests crash in std.mem.eqlBytes() Re-enable FastISel for MIPS O32 with LLVM 20 Sep 17, 2024
@alexrp alexrp self-assigned this Oct 3, 2024
@alexrp alexrp modified the milestones: 1.0.0, 0.15.0 Oct 3, 2024
richerfu pushed a commit to richerfu/zig that referenced this issue Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-mips 32-bit and 64-bit MIPS backend-llvm The LLVM backend outputs an LLVM IR Module. bug Observed behavior contradicts documented or intended behavior upstream An issue with a third party project that Zig uses.
Projects
None yet
Development

No branches or pull requests

2 participants