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

For functions that don't have arch/intrinsic versions, only run tests once #446

Open
tgross35 opened this issue Jan 15, 2025 · 0 comments
Open

Comments

@tgross35
Copy link
Contributor

tgross35 commented Jan 15, 2025

Currently the test run looks like this:

# Test once without intrinsics
$cmd

# Exclude the macros and utile crates from the rest of the tests to save CI
# runtime, they shouldn't have anything feature- or opt-level-dependent.
cmd="$cmd --exclude util --exclude libm-macros"

# Test once with intrinsics enabled
$cmd --features unstable-intrinsics
$cmd --features unstable-intrinsics --benches

# Test the same in release mode, which also increases coverage. Also ensure
# the soft float routines are checked.
$cmd "$profile" release-checked 
$cmd "$profile" release-checked --features force-soft-floats
$cmd "$profile" release-checked --features unstable-intrinsics
$cmd "$profile" release-checked --features unstable-intrinsics --benches

# Ensure that the routines do not panic.
ENSURE_NO_PANIC=1 cargo build -p libm --target "$target" --no-default-features --release

The non-release builds are quick enough that they don't matter, but most functions are getting tested three times in release mode. This is a lot of CI time, recent runs have been between 20 and 30 minutes with new tests included.

I think it is sufficient to run two sets of tests:

  1. Once with --features force-soft-floats, including only the functions that have arch-specific versions that only otherwise take precedence.
  2. Once with --features unstable-intrinsics, running all tests

We should be able to assume that if both our softfloat and arch-specific implementations are correct, any functions that make use of them will be correct with either implementation.

For the first set of tests (filtering out any tests that do not have an arch-specific version), we can probably use a nextest profile with a DSL filterset, which will exclude tests that do not have an arch version https://nexte.st/docs/filtersets/reference/. update-api-list.py can check that we aren't filtering out anything that we shouldn't be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant