<div dir="ltr">Do you think all of them deserve their own check ? Some of them already have a way to be expressed in the IR (no alias return for instance) but others seems like a pack of behavior that goes together for the most part.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-04 23:49 GMT+01:00 Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 01/04/2016 10:37 AM, Amaury SECHET wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
 - Allocation like functions.<br>
 - Runtime functions for managed languages, that touch state that the program itself can never touch directly.<br>
<br>
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>
</blockquote></span>
I've been looking at this some over the last week and have been trying to separate the component properties MemoryBuiltins provides.  So far, I have the following distinct properties:<br>
1) Aliasing - malloc and calloc are assumed not to modify any module visible value in MemoryDependenceAnalysis.  I believe this should be replaceable with inaccessiblememonly.<br>
2) Observability - We assume in InstCombine that allocation itself is not directly observable.  That is, we will remove an allocation site which is not otherwise used.  We assume the same for free.<br>
3) Infinite abstract heap - We assume that malloc only fails if out of memory and that out of memory is not a observable condition.  In particular, we will fold null checks to an unused malloc to false meaning that OOM may fail to be observed.<br>
4) Nullability - Operator new was hardcoded to return null.  This is split out in <a href="http://reviews.llvm.org/D15820" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15820</a> which I'll be submitting shortly.<br>
5) noalias - We assume that allocation returns a noalias pointer and that stores to that location are not observable unless the pointer is captured.<br>
6) Malloc/Free pairing - We assume that using the incorrect form of free is UB and thus we can pretend the proper form was used for all of the preceding.<br>
<br>
I think it's a bit too early to settle on a new attribute at this time.  I want to make each of the properties above explicit in the code and once that's done, we can see which of them are worth promoting to full blown attributes.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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>
 - If the allocator can be exposed (custom allocator use case) inaccessiblememonly is not usable while this is.<br>
 - Other allocation related optimizations can kick in (for instance InstCombiner::visitAllocSite).<br>
<br>
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>
Thought ?<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>