mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-24 17:30:12 +01:00
1b8a43a0ba
util_cpu_detect is an anti-pattern: it relies on callers high up in the call chain initializing a local implementation detail. As a real example, I added: ...a Mali compiler unit test ...that called bi_imm_f16() to construct an FP16 immediate ...that calls _mesa_float_to_half internally ...that calls util_get_cpu_caps internally, but only on x86_64! ...that relies on util_cpu_detect having been called before. As a consequence, this unit test: ...crashes on x86_64 with USE_X86_64_ASM set ...passes on every other architecture ...works on my local arm64 workstation and on my test board ...failed CI which runs on x86_64 ...needed to have a random util_cpu_detect() call sprinkled in. This is a bad design decision. It pollutes the tree with magic, it causes mysterious CI failures especially for non-x86_64 developers, and it is not justified by a micro-optimization. Instead, let's call util_cpu_detect directly from util_get_cpu_caps, avoiding the footgun where it fails to be called. This cleans up Mesa's design, simplifies the tree, and avoids a class of a (possibly platform-specific) failures. To mitigate the added overhead, wrap it all in a (fast) atomic load check and declare the whole thing as ATTRIBUTE_CONST so the compiler will CSE calls to util_cpu_detect. Co-authored-by: Alyssa Rosenzweig <alyssa@collabora.com> Reviewed-by: Marek Olšák <maraeo@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15580> |
||
|---|---|---|
| .. | ||
| check_output.py | ||
| framework.h | ||
| glsl_scraper.py | ||
| helpers.cpp | ||
| helpers.h | ||
| main.cpp | ||
| meson.build | ||
| README.md | ||
| test_assembler.cpp | ||
| test_builder.cpp | ||
| test_hard_clause.cpp | ||
| test_insert_nops.cpp | ||
| test_isel.cpp | ||
| test_optimizer.cpp | ||
| test_optimizer_postRA.cpp | ||
| test_regalloc.cpp | ||
| test_sdwa.cpp | ||
| test_tests.cpp | ||
| test_to_hw_instr.cpp | ||
Tests are wrapped in a BEGIN_TEST/END_TEST and write data to the output file pointer. Tests have checks against the output. They are single line comments prefixed with certain characters:
!fails the test if the current line does not match the pattern>>skips to the first line which matches the pattern, or fails the test if there is none;executes python code to extend the pattern syntax by inserting functions into the variable dictionary, fail the test, insert more checks or consume characters from the output
Before this prefix, there can be a ~ to only perform the check for certain
variants (a regex directly following the ~ is used).
Pattern Syntax
Patterns can define variables which can be accessed in both python code and the pattern itself. These are useful for readability or dealing with unstable identifiers in the output. Variable identifiers are sequences of digits, ascii letters or _ (though they cannot start with a digit).
\can be used to match the following literal character without interpreting it.- Most characters expect the same characters in the output.
- A sequence of spaces in the pattern expects a sequence of spaces or tabs in the output.
- A
#in the pattern expects an unsigned integer in the output. The#can be followed by an identifier to store the integer in a variable. - A
$in the pattern stores the output until the first whitespace character into a variable. - A
%in the pattern followed by an identifier is the same as a#but it expects a%before the integer in the output. It basically matches a ACO temporary. - A
@calls a variable as a function. It can be followed by an argument string wrapped in(and).
Functions
s64,s96,s128,v2,v3, etc, expand to a pattern which matches a disassembled instruction's definition or operand. It later checks that the size and alignment is what's expected.match_funcexpands to a sequence of$and inserts functions with expand to the extracted outputsearch_reconsumes the rest of the line and fails the test if the pattern is not found