[libc-dev] __builtin_* vs llvm-libc provided ones?

Ebrahim Byagowi via libc-dev libc-dev at lists.llvm.org
Mon Feb 1 02:58:08 PST 2021

To describe in maybe some better way, for example this is all I need to get
ceilf floorf etc in a .wasm module being built by -nostdlib -nostdinc

#define ceilf __builtin_ceilf
#define floorf __builtin_floorf
#define abs __builtin_abs
#define fabs __builtin_fabs

so I wondered if I could get more of libc this way (parts make sense ofc)
or at least to know what will be the relation between those builtin
implementations and the upcoming libc.

On Sat, Jan 30, 2021 at 9:30 PM Ebrahim Byagowi <ebraminio at gmail.com> wrote:

> There is e.g. __builtin_memcpy and even a __builtin_memcpy_inline in
> clang, and __builtin_memset_inline
> <https://github.com/llvm/llvm-project/blob/6ca54e0/libc/src/string/memory_utils/memset_utils.h#L20-L23> apparently
> is just a TODO right now.
> As __builtin_memcpy for example already has an implementation on llvm
> <https://github.com/llvm/llvm-project/blob/0da15ea/llvm/lib/IR/IRBuilder.cpp#L187-L209>
> but llvm-libc hasn't reused it and implemented it separately, maybe perhaps
> in order to not make llvm-libc a clang buildable only project as maybe some
> builtins aren't present in other compilers.
> My question is what is the plan about the two, accepting the duplication
> of implementations or removing non libc implementation in favor of llvm
> libc provided ones or the reverse way.
> I wonder if is there a future that all or most of the libc entries will
> also be provided by compiler's __builtin_* and maybe __builin_*_inline also
> thus resolving the TODO __builin_memset_inline by just reusing llvm-libc
> implementations somehow on IRBuilder.
> Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libc-dev/attachments/20210201/aa07d54f/attachment.html>

More information about the libc-dev mailing list