[libc][freebsd] skip exhaustive math tests in FreeBSD CI

[SchrodingerZhu]

Remove expensive tests to mitigate the long running time.

[llvmorg-github-actions]

@llvm/pr-subscribers-github-workflow

Author: Schrodinger ZHU Yifan (SchrodingerZhu)

Changes

---

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

1 Files Affected:

• (modified) .github/workflows/libc-freebsd-vm-tests.yml (+1-3)

diff --git a/.github/workflows/libc-freebsd-vm-tests.yml b/.github/workflows/libc-freebsd-vm-tests.yml
index 7f2d69c17c2c3..d4e5fe48033ec 100644
--- a/.github/workflows/libc-freebsd-vm-tests.yml
+++ b/.github/workflows/libc-freebsd-vm-tests.yml
@@ -30,7 +30,7 @@ jobs:
         run: |
           pkg update
           pkg upgrade -y
-          pkg install -y mpfr gmp mpc ninja cmake llvm22 python3
+          pkg install -y ninja cmake llvm22 python3
 
     # Use MinSizeRel to reduce the size of the build.
     # Notice that CMP0141=NEW and MSVC_DEBUG_INFORMATION_FORMAT=Embedded are required
@@ -43,8 +43,6 @@ jobs:
         -DCMAKE_C_COMPILER=clang22
         -DCMAKE_BUILD_TYPE=RelWithDebInfo
         -DLLVM_ENABLE_RUNTIMES=libc
-        -DLLVM_LIBC_MPFR_INSTALL_PATH=/usr/local
-        -DLIBC_MPC_INSTALL_PATH=/usr/local
         -G Ninja
         -S runtimes
 

[Copilot]

Pull request overview

This PR adjusts the FreeBSD VM CI workflow for LLVM-libc to reduce overall execution time by eliminating reliance on MPFR/GMP/MPC-based math testing infrastructure in that job.

Changes:

• Stop installing mpfr, gmp, and mpc in the FreeBSD VM setup step.
• Remove CMake cache entries that point libc’s MPFR/MPC detection to /usr/local.

[boomanaiden154]

Why are we going from full tests to build only?

What's the runtime like if we just disable the exhaustive math tests?

[lntue]

Why are we going from full tests to build only?

What's the runtime like if we just disable the exhaustive math tests?

I agree, let just disable the MPFR math tests first to see how much time it takes for the rest of them.

[SchrodingerZhu]

Pushed. Let's check the runtime first.

[SchrodingerZhu]

Discussed with @lntue, 26mins testing seems acceptable for now.