<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>For example, does Swift use malloc() to allocate its objects?</div><div><br>On May 23, 2016, at 10:18 AM, mats petersson <<a href="mailto:mats@planetcatfish.com">mats@planetcatfish.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div>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"?<br><br></div>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].<br><br><br></div>Sorry if I misunderstood your idea, as David says, maybe you need to explain a bit more... <br><br>--<br></div>Mats<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 May 2016 at 09:11, David Chisnall via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22 May 2016, at 20:32, Lorenzo Laneve via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I know, that's the problem.<br>
> 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.<br>
> 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.<br>
> I don't know if you get me.<br>
<br>
</span>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?<br>
<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></body></html>