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

[mats petersson via llvm-dev]

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