llvm dev - May 2016 - A "Cross-Platform Runtime Library API" in LLVM IR

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.
> On May 22, 2016, at 9:06 PM, Matthias Braun <matze at braunis.de>
wrote:
> 
> 
>> On May 22, 2016, at 10:31 AM, Lorenzo Laneve via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>> 
>> 
>> My idea is an API where anyone can build a Runtime Library for any
backend, including a set of functions people can inline/rename creating
functions the frontend can include in the IR.
>> 
>> For example implementing a cross-platform runtime function that
allocates memory for a new object. (Obviously the library will have to be
compiled for each target).
> Memory allocation is usually considered part of libc. There are several
libc implementations that target multiple architectures. musl, glibc, newlib,
diet libc to name just a few.
> 
> - Matthias
>

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

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>