Represent runtime preemption in the IR.

Authored by sfertile on Oct 26 2017, 8:00 AM.


Represent runtime preemption in the IR.

Currently we do not represent runtime preemption in the IR, which has several

  1. The semantics of GlobalValues differ depending on the object file format you are targeting (as well as the relocation-model and -fPIE value).
  2. We have no way of disabling inlining of run time interposable functions, since in the IR we only know if a function is link-time interposable. Because of this llvm cannot support elf-interposition semantics.
  3. In LTO builds of executables we will have extra knowledge that a symbol resolved to a local definition and can't be preemptable, but have no way to propagate that knowledge through the compiler.

This patch adds preemptability specifiers to the IR with the following meaning:

dso_local --> means the compiler may assume the symbol will resolve to a
definition within the current linkage unit and the symbol may be accessed
directly even if the definition is not within this compilation unit.

dso_preemptable --> means that the compiler must assume the GlobalValue may be
replaced with a definition from outside the current linkage unit at runtime.

To ease transitioning dso_preemptable is treated as a 'default' in that
low-level codegen will still do the same checks it did previously to see if a
symbol should be accessed indirectly. Eventually when IR producers emit the
specifiers on all Globalvalues we can change dso_preemptable to mean 'always
access indirectly', and remove the current logic.

Differential Revision: https://reviews.llvm.org/D20217

llvm-svn: 316668


sfertileOct 26 2017, 8:00 AM
Differential Revision
D20217: Represent runtime preemption in the IR.
rG2232243863bc: AMDGPU: Handle s_buffer_load_dword hazard on SI