[PATCH] D20217: Add direct control of whether or not a symbol is preemtable at runtime

Rafael Ávila de Espíndola via llvm-commits llvm-commits at lists.llvm.org
Thu May 12 11:43:36 PDT 2016


rafael created this revision.
rafael added reviewers: rnk, rjmccall, tmsriram.
rafael added a subscriber: llvm-commits.
Herald added a subscriber: joker.eph.

In the discussion D19995 it was noted that llvm's handling of runtime preemption has some problems

* It assumes it dosn't happen and then uses a got at the last minute for ELF.
* The semantics of the IR is dependent on the object format.
* The semantics of the IR is dependent on -fPIC

I proposed extending the IR with two extra linkages. One for strong,  but preemtable at runtime. Another for external,  but known local.

Trying to implemented that I noticed a problem: the proposal assumed an hierarchy of the linkages.  Anything that is preemtable at link time is preemptable at run time. That is not the case. For example, an inline c++ function is weak, but is not runtime preemptable if it is in the main executable in ELF.

What is needed is really another bit for runtime preemption. We already have a few special cases:

* visibility. But this one is mandatory. If a symbol is not default the linker requires it to be in this DSO.
* dllimport. This one goes only one way. It causes a declaration to be preemptable.

We could have just one bit that always means that a GV is preemptable. For example, just "declare void @foo" would be accessed with a lea and would require an preemptible bit to be accessed indirectly. That is what COFF does currently, but is a somewhat bit change for the other formats.

What I am currently experimenting with is that, by default, a GV is preemtable at rutime iff it is preemptable at link time and we have a bit in the GV to tell LLVM if that is not the case.

The attached patch is incomplete. It just adds .ll parsing, the basic IR infrastructure and changes the MachO codegen so that it can include a test.

Do you guys think this is a reasonable direction? If so I will add bitcode serialization support and upgrade and plug it to the other object formats.


http://reviews.llvm.org/D20217

Files:
  include/llvm/IR/GlobalValue.h
  lib/AsmParser/LLLexer.cpp
  lib/AsmParser/LLParser.cpp
  lib/AsmParser/LLParser.h
  lib/AsmParser/LLToken.h
  lib/IR/Globals.cpp
  lib/Target/X86/X86Subtarget.cpp
  test/CodeGen/X86/preemption.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D20217.57076.patch
Type: text/x-patch
Size: 18147 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160512/d80546ed/attachment.bin>


More information about the llvm-commits mailing list