[llvm-dev] A "Cross-Platform Runtime Library API" in LLVM IR

[Lorenzo Laneve via llvm-dev]

I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster.

And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed.

I'm just assuming that the functions we use in C such as malloc() are quite high-level interfaces and that there might be something faster.

For example, does Swift use malloc() to allocate its objects?

> On May 23, 2016, at 10:18 AM, mats petersson <mats at planetcatfish.com> wrote:
> 
> So, the backend should implement "__alloc" that does the same as "malloc" - or something subtly different from "malloc" - and on a Windows machine, how is it different from "HeapAlloc"? And "__write" that is same as UNIX "write", but different from "WriteFile" in Windows? And HOW do you expect the backend to implement these? By calling "malloc"/"HeapAlloc", "write"/"WriteFile"?
> 
> This is what the C library is for, it provides a set of independent functions that are reasonably well defined and reasonably portable between archiectures. If you are compiling something different than C, you'll need to implement something similar [and perhaps, like I did, interface to the C runtime library even in a non-C language with thin wrapper functions].
> 
> 
> Sorry if I misunderstood your idea, as David says, maybe you need to explain a bit more... 
> 
> --
> Mats
> 
>> On 23 May 2016 at 09:11, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On 22 May 2016, at 20:32, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> >
>> > I know, that's the problem.
>> > We can assume all of the system calls as runtime functions: such as I/O, allocations etc. and create a set of function implemented for all the architectures.
>> > For example, let's think about the mem allocation again: we can provide a primitive function with the same name for all archs (e.g. __alloc() ) and then people can include this function __alloc() in their libraries, inlining it or even renaming it just to fit the frontend needs. And this can be useful: every backend should implement this set of functions ( __alloc(), __free(), __write()… just for example) so the frontends can build a library with these functions as they want.
>> > I don't know if you get me.
>> 
>> I think you will need to explain a bit more.  We already have such a function, it’s called malloc() and a few LLVM passes assume specific behaviour about it.  What problem are you trying to solve?
>> 
>> David
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/2a7729e1/attachment.html>