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

[Siva Chandra via libc-dev]

On Tue, Feb 2, 2021 at 12:03 PM Ebrahim Byagowi <ebraminio at gmail.com> wrote:

> 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?
>

One could make that work I guess (with a lot of caveats). But, we want to
be able to build and test LLVM libc without the rest of LLVM. This is
currently not possible because of the tablegen dependency but we are still
searching for good alternates. In the meanwhile, we don't want to add any
more dependency from outside of the libc sources.


> 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/9630ab24/attachment.html>