[RFC] The callback attribute and abstract call sites

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[RFC] The callback attribute and abstract call sites

Richard Smith via cfe-dev
This is a follow up to my talk at the LLVMDev'18 meeting:
  https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk20


tl;dr

We want to introduce the notation of a transitive and abstract call
sites into LLVM in order to improve IPO in the presence of function
pointers passed to (runtime) functions. A description, examples, and the
implementation can be found here [0].

We also want Clang to emit !callback metadata for library functions with
known callback behavior (pthread_create, qsort_r, __kmpc_fork_call,
__kmpc_fork_teams for now), as well as for manually annotated functions
that carry the "callback" attribute. Our implementation can be found
here [1].

---

A callback is the transfer of control through a (potentially opaque)
broker function to some known piece of code. This is common in various
scenarios, including the implementation of parallelism. Since the
control transfer is hidden, our IPOs cannot be applied. While a
dedicated "parallel-IR" could solve this problem, we do not have a
"sound" proposal and it would most likely not cover the non-parallelism
related callback cases.

To apply IPOs seamlessly to both, direct and callback call sites, we
proposed the concept of an abstract call site. It can either represent
an existing direct call site, or a transitive (callback) call site. The
interface is a stripped down version of the existing call site which
allows us to reuse most IPOs with minimal changes (see [0] for an
example).

To enable automatic optimization of callbacks, we extended clang to
annotate known callback "broker" functions with appropriate metadata
(see [1] for the clang parts and [0] for the metadata). User annotations
are allowed as well so other library will be able to benefit from the
same improvements.

---

Since the feedback after the LLVM developers meeting was very positive,
and the patches went through an initial round of feedback without
conceptual criticism, it seems time to give a broader community the
opportunity to comment.


Thanks,
  Johannes


[0] https://reviews.llvm.org/D54498
[1] https://reviews.llvm.org/D55483

--

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

[hidden email]

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (235 bytes) Download Attachment