From e351ee3b7f3eb2023b8c391b0db2655707183e62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alex=20R=C3=B8nne=20Petersen?= <alex@alexrp.com>
Date: Sat, 2 Aug 2025 21:24:42 +0200
Subject: [PATCH] Revert "llvm: workaround crashes in llvm loop optimizations"

This reverts commit b4fd57a9c114748afb9ba0a04bede61089a02ddf.

https://github.com/llvm/llvm-project/pull/149743
---
 src/codegen/llvm.zig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/codegen/llvm.zig b/src/codegen/llvm.zig
index b9e17d06e9..04f964d68a 100644
--- a/src/codegen/llvm.zig
+++ b/src/codegen/llvm.zig
@@ -6412,9 +6412,6 @@ pub const FuncGen = struct {
             // * https://github.com/llvm/llvm-project/blob/56905dab7da50bccfcceaeb496b206ff476127e1/llvm/test/MC/WebAssembly/blockaddress.ll
             if (zcu.comp.getTarget().cpu.arch.isWasm()) break :jmp_table null;
 
-            // Workaround for https://github.com/ziglang/zig/issues/24383:
-            if (self.ng.ownerModule().optimize_mode == .ReleaseSafe) break :jmp_table null;
-
             // On a 64-bit target, 1024 pointers in our jump table is about 8K of pointers. This seems just
             // about acceptable - it won't fill L1d cache on most CPUs.
             const max_table_len = 1024;