On 12/29/2025 8:19 AM, Tamar Christina wrote:
The following testcase
void f (float *__restrict c, int *__restrict d, int n)
{
for (int i = 0; i < n; i++)
{
if (d[i] > 1000)
c[i] = __builtin_sqrtf (c[i]);
}
}
compiled with -O3 -march=armv9-a -fno-math-errno -ftrapping-math
vectorizes as:
f:
cmp w2, 0
ble .L1
mov x3, 0
mov w4, 1000
whilelo p7.s, wzr, w2
mov z31.s, w4
ptrue p6.b, all
.L3:
ld1w z0.s, p7/z, [x1, x3, lsl 2]
cmpgt p7.s, p7/z, z0.s, z31.s
ld1w z30.s, p7/z, [x0, x3, lsl 2]
fsqrt z30.s, p6/m, z30.s
st1w z30.s, p7, [x0, x3, lsl 2]
incw x3
whilelo p7.s, w3, w2
b.any .L3
.L1:
ret
which is incorrect, fsqrt can raise FE exceptions and so should be masked on p7
as the inactive lanes can trigger incorrect FE errors as the code in the PR
demonstrates.
In GCC 13 this was partially addressed for instruction that got lowered to IFNs
through r13-5979-gb9c78605039f839f3c79ad8fca4f60ea9a5654ed but it never
addressed __builtin_math_fns. Assuming the direction of travel in PR96373 is
still valid this extends the support.
While ERRNO trapping is controlled through flags, it looks like for trapping
math the calls and IFNs are not marked specifically. Instead in
gimple_could_trap_p_1 through operation_could_trap_p we default to all floating
point operation could trap if flag_trapping_math.
This extends gimple_could_trap_p_1 to do the same for __builtin_math_fns but
exclude instructions that the standard says can't raise FEs.
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
-m32, -m64 and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR tree-optimization/122103
* gimple.cc (gimple_could_trap_p_1): Handle __builtin_ calls.
Seems suitably conservative. OK for the trunk.
Jeff
