[llvm-dev] help with clarifying function attributes
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Fri Apr 19 19:06:11 PDT 2019
(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 ) 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").
> 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  there is a patch  to propagate it if only
"inaccessiblememonly" functions are called. There is a proposed GSoC
project  which could bring this attribute to C headers, though that
is another story ;)
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  above for all function attributes. You might
I also linked our ISC'19 paper  below. Section 3 describes various
attributes in LLVM-IR, including the ones above (in 3.4.2).
> Any replies are appreciated.
Argonne National Laboratory
Lemont, IL 60439, USA
jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the llvm-dev