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

[mats petersson via llvm-dev]

On 23 May 2016 at 12:16, Lorenzo Laneve <lore97drk at icloud.com> wrote:

> I'm not talking about a new library instead of the libc, I'm talking about
> letting people create a library optimized for a specific frontend,
> regardless of the target.
>

But HOW is that going to work for multiple languages, on multiple hardware
platforms. And have you got ANY evidence that the extra call level between
C++'s `operator new` and `malloc` actually causes noticeable overhead?

--
Mats

>
> > On May 23, 2016, at 1:06 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk>
> wrote:
> >
> >> On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote:
> >>
> >> This is the point,
> >
> > No, you are still failing to make a point.
> >
> >> High-level OO languages don't use malloc(), they use something else.
> >
> > That’s not entirely true.  They need to get the memory that they provide
> to programs from somewhere.  They may provide their own pool allocators,
> but they will often just call malloc() and then subdivide the returned
> chunk.  If they’re doing garbage collection, they will ask for a large
> number of pages and use that as a heap managed by the garbage collector.
> >
> >> My idea was a C API with implementations of functions:
> >> For example
> >> Assuming I need to implement a function which allocates a new object.
> >> The API provides a really basic allocator function I can use to
> implement the complete function the high-level language needs.
> >>
> >> void *__newobject(int class_size) {
> >> void *r = __alloc(class_size);
> >> // Add GC metadata here
> >> return r;
> >> }
> >
> > You have still completely failed to explain why __alloc() is better than
> malloc().  If you wish to implement a language-specific allocator like
> this, then why would it want to call __alloc() from your hypothetical
> library instead of malloc(), provided by something like jemalloc(), which
> has over a decade of careful optimisation behind it to ensure that it
> scales well on multithreaded systems?
> >
> >> This function will be included in the runtime library. Obviously this
> is a stupid example maybe a better implementation can be done.
> >
> > Again, why would I, as the author of a high-level language, want to
> depend on your runtime library?  You have not given a compelling use case
> for someone wanting to depend on your hypothetical runtime library instead
> of the target platform’s libc.  If I write my language-specific code
> against libc, then other people will implement the platform-specific parts
> for me.  I can rely on C interfaces existing on pretty much any platform
> that I want to target, from desktop and server operating systems down to
> real-time embedded operating systems.  What does your proposal give me?
> >
> > David
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/abcaa1a0/attachment.html>