[llvm-dev] Optimizing memory allocation for custom allocators and non C code

[Amaury SECHET via llvm-dev]

I had this on my TODO list for a while, but the recent introduction of
inaccessiblememonly makes it suddenly more urgent, as there is a risk to
waste effort in duplicated work and/or end up with suboptimal solutions. I
collected 2 use cases for inaccessiblememonly :
 - Allocation like functions.
 - Runtime functions for managed languages, that touch state that the
program itself can never touch directly.

My initial reflection was that MemoryBuiltins use a set of hardcoded
functions to do its magic. Doing so, it support the C API fairly well, some
variation of the operator new, and that's it. It seems unlikely and counter
productive that all language dump their runtime in there, and won't work
when feature like C++ templates comes in.

It seemed to me that adding attribute for allocation like function would be
useful. I think this road is superior to the inaccessiblememonly when it
come to memory allocation for the following reason:
 - If the allocator can be exposed (custom allocator use case)
inaccessiblememonly is not usable while this is.
 - Other allocation related optimizations can kick in (for instance
InstCombiner::visitAllocSite).

I think it is fair to keep this attribute for the managed language use
case, for instance, to improve GlobalsAA, but we should definitively
restrict it to function that are declared but NOT defined. When merging
modules, if a function with the attribute becomes defined, then it needs to
be thrown out. I don't think it would be that hard to do in practice, and
would greatly improves usability of inaccessiblememonly by making it safe
to merge modules.

Thought ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160104/8286301f/attachment.html>