[llvm-dev] A "Cross-Platform Runtime Library API" in LLVM IR
Lorenzo Laneve via llvm-dev
llvm-dev at lists.llvm.org
Mon May 23 02:13:06 PDT 2016
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...
>> 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?
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev