summaryrefslogtreecommitdiffstats
path: root/llvm/docs/LangRef.rst
diff options
context:
space:
mode:
authorTim Shen <timshen91@gmail.com>2016-04-19 19:40:37 +0000
committerTim Shen <timshen91@gmail.com>2016-04-19 19:40:37 +0000
commite885d5e4d3fffc40173a8d0c82a6d30b2400bdec (patch)
treedf73b907fb0243009111f03cdab04f5b55c22d7d /llvm/docs/LangRef.rst
parent6e39e0ba8766f5f317317385705aba309f023beb (diff)
downloadbcm5719-llvm-e885d5e4d3fffc40173a8d0c82a6d30b2400bdec.tar.gz
bcm5719-llvm-e885d5e4d3fffc40173a8d0c82a6d30b2400bdec.zip
[SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARD
With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there are still IR form stack guard customizations around (see getIRStackGuard()). Future SSP customization should go through LOAD_STACK_GUARD. There is a behavior change: stack guard values are not CSEed anymore, since we should never reuse the value in case that it has been spilled (and corrupted). See ssp-guard-spill.ll. This also cause the change of stack size and codegen in X86 and AArch64 test cases. Ideally we'd like to know if the guard created in llvm.stackprotector() gets spilled or not. If the value is spilled, discard the value and reload stack guard; otherwise reuse the value. This can be done by teaching register allocator to know how to rematerialize LOAD_STACK_GUARD and force a rematerialization (which seems hard), or check for spilling in expandPostRAPseudo. It only makes sense when the stack guard is a global variable, which requires more instructions to load. Anyway, this seems to go out of the scope of the current patch. llvm-svn: 266806
Diffstat (limited to 'llvm/docs/LangRef.rst')
-rw-r--r--llvm/docs/LangRef.rst35
1 files changed, 35 insertions, 0 deletions
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 2582e4aa0a5..8b0bedcd534 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -11996,6 +11996,41 @@ checked against the original guard by ``llvm.stackprotectorcheck``. If they are
different, then ``llvm.stackprotectorcheck`` causes the program to abort by
calling the ``__stack_chk_fail()`` function.
+'``llvm.stackguard``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+ declare i8* @llvm.stackguard()
+
+Overview:
+"""""""""
+
+The ``llvm.stackguard`` intrinsic returns the system stack guard value.
+
+It should not be generated by frontends, since it is only for internal usage.
+The reason why we create this intrinsic is that we still support IR form Stack
+Protector in FastISel.
+
+Arguments:
+""""""""""
+
+None.
+
+Semantics:
+""""""""""
+
+On some platforms, the value returned by this intrinsic remains unchanged
+between loads in the same thread. On other platforms, it returns the same
+global variable value, if any, e.g. ``@__stack_chk_guard``.
+
+Currently some platforms have IR-level customized stack guard loading (e.g.
+X86 Linux) that is not handled by ``llvm.stackguard()``, while they should be
+in the future.
+
'``llvm.objectsize``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OpenPOWER on IntegriCloud