[libc-commits] [PATCH] D139064: Onboard signbitf to llvmlibc math functions.

Renyi Chen via Phabricator via libc-commits libc-commits at lists.llvm.org
Fri Dec 2 15:06:21 PST 2022


renyichen added inline comments.


================
Comment at: libc/spec/stdc.td:467
 
+          FunctionSpec<"signbitf", RetValSpec<BoolType>, [ArgSpec<FloatType>]>,
+
----------------
sivachandra wrote:
> renyichen wrote:
> > sivachandra wrote:
> > > Is `signbitf` really specified by the C standard? For that matter, any standard at all? I think standards only specify a generic `signbit` macro which can be implemented as:
> > > 
> > > ```
> > > #define signbit(x) __builtin_signbit(x)
> > > ```
> > I see (I should but didn't check the C standard). I probably should implement this in a separate code change-list.
> > 
> > Thanks for the insight and I have several questions (which does not necessarily make sense =p): do we plan to implement a bunch of functions that rely on __builtin_functions (isnan, isfinite, is_greater etc)? If so, can we rely on the __builtin_functions in terms of existence/correctness/speed of builtin functions given that llvmlibc has its own fputils?
> > 
> For items like `isnan`, `signbit` etc., all that needs to be done is to read one bit from the encoded floating point object. So, the builtins should not create recursive calls back to the libc. What will they call even if they want to as there is no equivalent libc function? It could be that a particular builtin is not implemented for a certain target. We can revisit your patch if and when we encounter such a target. 
Thanks for the explanation! I talked with lntue@ offline, and decided to leave `isnan`, `signbit` etc as they are for now and try to implement other functions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139064/new/

https://reviews.llvm.org/D139064



More information about the libc-commits mailing list