I seem to have created a few issues. https://buildbot.halide-lang.org/master/#/builders/98/builds/88 (halide-testbranch-main-llvm20-arm-64-osx-cmake) shows useful errors. Will address them.

Is this Windows issue fixed by now?

JIT session error: could not register eh-frame: __register_frame function not found
Assertion failed: !G && "InFlight alloc neither abandoned nor finalized", file C:\build_bot\worker\llvm-20-x86-64-windows\llvm-project\llvm\lib\ExecutionEngine\JITLink\JITLinkMemoryManager.cpp, line 251

@steven-johnson Could you request a rebuild for those failed build bots?

Working on the windows error in #8615

@alexreinking Can you fix mac-x86-worker-2: Python package numpy is no found. If that one is not found, I'm assuming it's a fresh install and more stuff might be missing...

@abadams can you assess the test failure on arm. There is a hexagon related test that failed. I doubt it is related to my work.
@derek-gerstmann can you assess the test failure on Windows? I don't see any error.

@mcourteaux The test failure on Windows was the correctness_math test on the Vulkan backend segfaulting due to a failed compilation for mismatched types for built-in constants for inf_f32, neg_inf_f32, and nan_f32. These are handled as extern calls and they assumed they were always scalars, which caused the pow vector x2 tests to fail. I've pushed fixes to make sure proper vector constants are generated.

I will defer to Derek for approval

Well, so my motivation was:

1. Halide uses suffixes for floating-point math functions, like _f32, _f64, _f16.
2. Every graphics API spec declares those math functions, but are tend to have different names, depending on the API (e.g., fabs() vs overloaded abs()).
3. Not every API provides implementations for f16 or f64 variants of the math functions.

As such, general-purpose Halide IR must use sin_f32 as the function to compute sine of (a vector of) 32-bit floats. Halide's C backend runtime provides those functions explicitly and simply redirects them to libm (sin, sinf), and we pay for the extra function-call overhead. LLVM-based backends automatically scalarize those calls.

Given the above, a general-purpose mapping table in the C codegen base-class seemed like the right place to put all of this shared functionality to rewrite extern function calls to have different function names (e.g., from sin_f32 to sin).

In general, there is a lot less code now, compared to all of the #defines in the shader code.
The alias macros each write 2 or 3 renaming entries into the table. But as I said, automating the generation of those entries is not elegant, as every backend uses different naming schemes, and some don't even provide functionality with the same semantics as we expect (i.e., WebGPU with pow()). In my opinion, I replaced several long tables with several short tables, with increased functionality (i.e., support for vector-arguments).

Ping @derek-gerstmann.