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

[Ebrahim Byagowi via libc-dev]

Thank you so much.

With your explanation now I understand builtins propose better now I think, I
was also wrong about __builtin_memcpy_inline as it isn't as flexible as
a real libc memcpy and needs its third argument to be a constant, "error:
argument to '__builtin_memcpy_inline' must be a constant int…" (which I
wished it wasn't the case but is understandable why it is) and now I
see __builtin_memcpy
is also a proxy to libc memcpy which I guess is there just to make compiler
code analysis easier.

Now given that, not as a macro but is it possible to use the builtins
inside llvm-libc implementation maybe so llvm-libc won't have to implement
them again? I mean do you see it possible for llvm-libc to get its
implementation shared with compiler one somehow behind the scene? Maybe
through some directory inside somewhere that the both compiler and
llvm-libc can share their implementations of those?

The reason I'm asking is because of a hope I have to see compiler builtins
some day to be more capable, which I understand I shouldn't be that hopeful
about it, but I think the questions can be thought about regardless.

Thanks!

On Tue, Feb 2, 2021 at 10:38 PM Siva Chandra <sivachandra at google.com> wrote:

> On Mon, Feb 1, 2021 at 2:58 AM Ebrahim Byagowi <ebraminio at gmail.com>
> wrote:
>
>> 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.
>>
>
> IIUC, there are two parts to your question:
> 1. Can we implement a libc function as a macro resolving to a builtin: Not
> if the standard requires the function to be a real addressable function.
> One can choose to also provide a macro, but an addressable function
> declaration should be available. See section 7.1.4 of the C11 standard for
> more information.
> 2. What is the difference between builtins and the libc flavors of the
> functions: Typically, builtins resolve to the hardware instruction
> implementing the operation. If a hardware implementation is not available,
> the compiler builtin calls into the libc itself. With respect to math
> functions, you will notice this wilh the `long double` flavors. That said,
> we have implemented the math functions from first principles (as in, the
> implementations do not assume any special hardware support) in LLVM libc.
> However, we are just about starting to add machine specific implementations
> (https://reviews.llvm.org/D95850). This should make the libc functions
> equivalent to the compiler builtins.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libc-dev/attachments/20210202/e91bf990/attachment.html>