Repository navigation
Test BFloat16 arithmetic against exactly rounded references - #952
Merged
Merged
Conversation
The arithmetic tests rounded their references with the host's `BFloat16` conversion inside a vectorizable `map`. LLVM 19 to 22 (Julia 1.13) miscompiles that for AArch64 targets without BF16: an `<8 x bfloat>` operation takes its round-to-even bit from an operand rather than the result, so some ties round the wrong way. Round them with `bf16_nearest` instead, as the conversion tests already do. `bf16_nearest` kept 8 significant bits, which is too many for bfloat16 subnormals, so subnormal quotients were rounded twice. Round those to multiples of 2^-133. PoCL's LLVM 22 has the same bug on the device side, so the tests still fail on such targets with the current pocl_standalone_jll (#949).
maleadt
added
upstream
Contributor
Benchmark resultsCompared with a13691a5b, the merge base. Times are the minimum time of every benchmark. A change is unusual when it exceeds both three times the benchmark's typical change between consecutive runs on the default branch and a minimum per category (performance 3%, latency 5%, applications 3%, other 3%). A benchmark that starts or stops allocating is listed however few the allocations. A single run can still be a fluke, so rerun before drawing conclusions.
All benchmarks
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #952 +/- ##
==========================================
- Coverage 84.91% 84.11% -0.81%
==========================================
Files 31 31
Lines 2612 2562 -50
==========================================
- Hits 2218 2155 -63
- Misses 394 407 +13 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #949. The BFloat16 tests fail on AArch64 when compiling for a target without BF16, as on Apple M2 and M5 (whose CPUs have it, but Julia targets
apple-m1there, and PoCL apparently a similar model) and on a Neoverse-N1, for two reasons. LLVM 19 to 22 round<8 x bfloat>fadd/fsub/fmul/fdiv wrongly there: theround_v4fp32_to_v4bf16pattern inAArch64InstrInfo.tdtakes the round-to-even bit from an operand rather than from the result, so ties can round the wrong way. LLVM 23 removed those patterns (llvm/llvm-project#190164). That bug affects both sides of the test:pocl_standalone_jlluses LLVM 22. The fix is to build it with LLVM 23; a Yggdrasil change moving the experimentalpocl_standalone_nextto LLVM 23 is ready, to try that first.BFloat16conversion inside a vectorizablemap, which Julia 1.13 (LLVM 20) miscompiles in the same way. On a Neoverse-N1, the device results from an LLVM 23 PoCL were exact, but 21 of 4096 references were not.This PR fixes the references. It computes them with
bf16_nearest, as the conversion tests already do.bf16_nearestitself double-rounded subnormal results, since it kept 8 significant bits, which bfloat16 subnormals don't have. It now rounds those to multiples of 2^-133. It matches an integer round-to-nearest-even on all Float32 inputs checked, including every subnormal tie.Results, Julia 1.13, 5 runs each:
pocl_standalone_jll(LLVM 22)pocl_standalone_next(LLVM 23, local build)So on such CPUs the test still fails with the current JLL, now only because of the device, until
pocl_standalonemoves to LLVM 23. The full test suite passes on x86_64 with both libraries on Julia 1.13, and with the current one on Julia 1.10.