Doerfert, Johannes via llvm-dev
2019-Apr-20 02:06 UTC
[llvm-dev] help with clarifying function attributes
Hi Gracia, (Same email as before without attached pdf but with a link to it.) On 04/19, Shiyao Ge via llvm-dev wrote:> I read about the lib function attributes deduction lately and got confused > about the OnlyAccessesInaccessibleMem function atrribute. The explaining > text is "function may only access memory that is either inaccessible from > the IR or pointed to by its argument".That is the definition of "inaccessiblemem_or_argmemonly" and not "inaccessiblememonly" (function attribute spelling, see [1]) which would correspond to OnlyAccessesInaccessibleMem. I'll assume the latter in this mail, which has the same meaning as the former but without the argument part (="or pointed to by its arguments"). [1] http://llvm.org/docs/LangRef.html#function-attributes> So what kind of function can be annotated with this attribute, > functions which malloc heap memory and free it within the same scope?Short answer: Yes, we probably could but do not do it right now. Longer answer below. Also consider the use case of (known) function defined in another translation unit (=module). They could then even work on some global state, e.g., a global variable, if it never "leaks" out of the other scope. Right now, if I remember correctly, we actually do not "deduce" "inaccessiblememonly", nor do we propagate it. For the proposed Attributor framework [2] there is a patch [3] to propagate it if only "inaccessiblememonly" functions are called. There is a proposed GSoC project [4] which could bring this attribute to C headers, though that is another story ;) [2] https://reviews.llvm.org/D59918 [3] https://reviews.llvm.org/D60077 [4] http://llvm.org/OpenProjects.html#header-generation Longer answer for the malloc-free scenario you mentioned: The answer depends on how you interpret the malloc and free semantic. In your scenario, and from the callers perspective, the memory accesses are not observable. If we assume alloc (and the implicit free at the return) it would not be distinguishable from readnone, so readnone would be appropriate. I'd argue the same would hold if (1) malloc and free would never fail and (2) be perfectly opposing functions, meaning the global state after a malloc-free sequence is the same as before. Since malloc does however modify some global state and there is no guarantee that it will go back to the way it was after free, we cannot deduce readnone here. It is however reasonable to assume that the state used to orchestrate malloc and free (and friends) is only accessible by these functions. Since that is the only state malloc/free/... access, they can be marked as "inaccessiblememonly". Using the fact that malloc also returns a no-alias pointer, and assuming it doesn't escape in the scenario you describe, we can mark the function using only malloc, free, and the allocated memory as "inaccessiblememonly".> Besides, I spot the attribute onlyaccessesargmem is used in AA to determine > ModRef behavior of functions and there is another ModRef behavior named as > OnlyReadArgMem, does it means we could have another function attribute > added to serve the purpose?Already existing, see [1] above for all function attributes. You might like: speculatable readnone readonly readonly argmemonly inaccessiblememonly inaccessiblemem_or_argmemonly I also linked our ISC'19 paper [5] below. Section 3 describes various attributes in LLVM-IR, including the ones above (in 3.4.2). [5] https://github.com/jdoerfert/PETOSPA/blob/master/ISC19.pdf Cheers, Johannes> Any replies are appreciated. > > Regards, > Gracia-- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 60439, USA jdoerfert at anl.gov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190420/ef23fd40/attachment.sig>