<div dir="ltr"><div dir="ltr">On Tue, Feb 2, 2021 at 12:03 PM Ebrahim Byagowi <<a href="mailto:ebraminio@gmail.com">ebraminio@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thank you so much.<div><br></div><div>With your explanation now I understand builtins propose better now I think, <span style="color:rgb(0,0,0)">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 </span>__builtin_memcpy is also a proxy to libc memcpy which I guess is there just to make compiler code analysis easier.</div><div><br></div><div>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?</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>Thanks!</div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 2, 2021 at 10:38 PM Siva Chandra <<a href="mailto:sivachandra@google.com" target="_blank">sivachandra@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Feb 1, 2021 at 2:58 AM Ebrahim Byagowi <<a href="mailto:ebraminio@gmail.com" target="_blank">ebraminio@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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<div><div><br></div><div>#define ceilf __builtin_ceilf</div><div>#define floorf __builtin_floorf</div><div>#define abs __builtin_abs</div><div>#define fabs __builtin_fabs</div></div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>IIUC, there are two parts to your question:</div><div>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.</div><div>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 (<a href="https://reviews.llvm.org/D95850" target="_blank">https://reviews.llvm.org/D95850</a>). This should make the libc functions equivalent to the compiler builtins.</div></div></div>
</blockquote></div>
</blockquote></div></div>