[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