Optimizing functions that compute absolute values of x

[k-arrows]

Test code:

#include <stdlib.h>
#include <math.h>

float f1(float x)
{
    return fabsf(x);
}

float f2(float x)
{
    return sqrtf(x * x);
}

float f3(float x)
{
    return (x >= 0.0f) ? x : -x;
}

float f4(float x)
{
    if(x >= 0.0f) return x;
    else return -x;
}

GCC:

f1:
        fabs    s0, s0
        ret
f2:
        fmul    s0, s0, s0
        fsqrt   s0, s0
        ret
f3:
        fabs    s0, s0
        ret
f4:
        fabs    s0, s0
        ret

Clang:

f1:                                     // @f1
        fabs    s0, s0
        ret
f2:                                     // @f2
        fabs    s0, s0
        ret
f3:                                     // @f3
        fabs    s0, s0
        ret
f4:                                     // @f4
        fneg    s1, s0
        fcmp    s0, #0.0
        fcsel   s0, s1, s0, lt
        ret

https://godbolt.org/z/EercfYfnd

Interestingly, Clang generates different code for f4 and so does GCC for f2.

[junaire]

Looks like an InstCombine issue? https://godbolt.org/z/Kq4PhrvGh

[MaxGraey]

At least, f3 and f4 transformations are not valid for negative zeros. Proof:

https://alive2.llvm.org/ce/z/aeSFxr

[k-arrows]

At least, f3 and f4 transformations are not valid for negative zeros. Proof:

https://alive2.llvm.org/ce/z/aeSFxr

Thank you for your explanation. I understand negative zero and positive zero are considered to be equal if we compare them with operator like ==.

But if -ffast-math is enabled, GCC transforms f4 into fabs but Clang does not.

[junaire]

At least, f3 and f4 transformations are not valid for negative zeros. Proof:
https://alive2.llvm.org/ce/z/aeSFxr

Thank you for your explanation. I understand negative zero and positive zero are considered to be equal if we compare them with operator like ==.

But if -ffast-math is enabled, GCC transforms f4 into fabs but Clang does not.

Yes, -Ofast is a must to enable this optimization. IIUC, the underlying reason is that LLVM doesn't correctly canonicalize the two forms of select into one. https://godbolt.org/z/5h8eWfr9d

However, I am not unsure about it. CC @rotateright @nikic for help.

[junaire]

No, we actually have transforms that can handle ult cases:

llvm-project/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp

Lines 2721 to 2732 in d8efbcf

	// With nsz, when 'Swap' is false:
	// fold (X < +/-0.0) ? -X : X or (X <= +/-0.0) ? -X : X to fabs(X)
	// fold (X > +/-0.0) ? -X : X or (X >= +/-0.0) ? -X : X to -fabs(x)
	// when 'Swap' is true:
	// fold (X > +/-0.0) ? X : -X or (X >= +/-0.0) ? X : -X to fabs(X)
	// fold (X < +/-0.0) ? X : -X or (X <= +/-0.0) ? X : -X to -fabs(X)
	//
	// Note: We require "nnan" for this fold because fcmp ignores the signbit
	// of NAN, but IEEE-754 specifies the signbit of NAN values with
	// fneg/fabs operations.
	if (!SI.hasNoSignedZeros() || !SI.hasNoNaNs())
	return nullptr;

But for some reason, f4 doesn't have nsz flag so it fails...