[libclc] [libclc] Move minmag & maxmag to the CLC library (PR #137982)
Fraser Cormack via cfe-commits
cfe-commits at lists.llvm.org
Thu May 1 01:43:36 PDT 2025
================
@@ -0,0 +1,18 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+_CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE __clc_maxmag(__CLC_GENTYPE x,
+ __CLC_GENTYPE y) {
+ const __CLC_GENTYPE res = __clc_select(
+ y, x,
+ __CLC_CONVERT_BIT_INTN(__clc_isgreater(__clc_fabs(x), __clc_fabs(y))));
+ return __clc_select(
+ res, __clc_fmax(x, y),
+ __CLC_CONVERT_BIT_INTN(__clc_isnan(x) || __clc_isnan(y) ||
+ __clc_isequal(__clc_fabs(x), __clc_fabs(y))));
----------------
frasercrmck wrote:
Yeah, it does seem excessive. I don't really understand the `isequal`.
The conversions are necessary because `select` only accepts conditions of the same size as the vector, but the *scalar* relational functions unhelpfully return `int` even for `double`. There's no implicit conversions on vector types so we need the explicit select. This all comes out in the wash as in LLVM IR it's just `i1` types fed from comparison to select anyway.
I've been wondering if we could alleviate this through extra overloads of `__clc_select` that accept intN conditions across the board, but that might also lead to some confusion.
https://github.com/llvm/llvm-project/pull/137982
More information about the cfe-commits
mailing list