[llvm-dev] help with clarifying function attributes

[Doerfert, Johannes via llvm-dev]

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>