<div dir="ltr"><div><div><div><div><div><div><div>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 :<br></div><div> - Allocation like functions.<br> - Runtime functions for managed languages, that touch state that the program itself can never touch directly.</div><div><br></div>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.<br><br></div>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:<br></div> - If the allocator can be exposed (custom allocator use case) inaccessiblememonly is not usable while this is.<br></div> - Other allocation related optimizations can kick in (for instance InstCombiner::visitAllocSite).<br><br></div></div>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.<br><br></div>Thought ?<br></div>