LLVM backend for 6502
Go to file
Michael Gottesman 657484f494 Teach selectiondag how to handle the stackprotectorcheck intrinsic.
Previously, generation of stack protectors was done exclusively in the
pre-SelectionDAG Codegen LLVM IR Pass "Stack Protector". This necessitated
splitting basic blocks at the IR level to create the success/failure basic
blocks in the tail of the basic block in question. As a result of this,
calls that would have qualified for the sibling call optimization were no
longer eligible for optimization since said calls were no longer right in
the "tail position" (i.e. the immediate predecessor of a ReturnInst
instruction).

Then it was noticed that since the sibling call optimization causes the
callee to reuse the caller's stack, if we could delay the generation of
the stack protector check until later in CodeGen after the sibling call
decision was made, we get both the tail call optimization and the stack
protector check!

A few goals in solving this problem were:

  1. Preserve the architecture independence of stack protector generation.

  2. Preserve the normal IR level stack protector check for platforms like
     OpenBSD for which we support platform specific stack protector
     generation.

The main problem that guided the present solution is that one can not
solve this problem in an architecture independent manner at the IR level
only. This is because:

  1. The decision on whether or not to perform a sibling call on certain
     platforms (for instance i386) requires lower level information
     related to available registers that can not be known at the IR level.

  2. Even if the previous point were not true, the decision on whether to
     perform a tail call is done in LowerCallTo in SelectionDAG which
     occurs after the Stack Protector Pass. As a result, one would need to
     put the relevant callinst into the stack protector check success
     basic block (where the return inst is placed) and then move it back
     later at SelectionDAG/MI time before the stack protector check if the
     tail call optimization failed. The MI level option was nixed
     immediately since it would require platform specific pattern
     matching. The SelectionDAG level option was nixed because
     SelectionDAG only processes one IR level basic block at a time
     implying one could not create a DAG Combine to move the callinst.

To get around this problem a few things were realized:

  1. While one can not handle multiple IR level basic blocks at the
     SelectionDAG Level, one can generate multiple machine basic blocks
     for one IR level basic block. This is how we handle bit tests and
     switches.

  2. At the MI level, tail calls are represented via a special return
     MIInst called "tcreturn". Thus if we know the basic block in which we
     wish to insert the stack protector check, we get the correct behavior
     by always inserting the stack protector check right before the return
     statement. This is a "magical transformation" since no matter where
     the stack protector check intrinsic is, we always insert the stack
     protector check code at the end of the BB.

Given the aforementioned constraints, the following solution was devised:

  1. On platforms that do not support SelectionDAG stack protector check
     generation, allow for the normal IR level stack protector check
     generation to continue.

  2. On platforms that do support SelectionDAG stack protector check
     generation:

    a. Use the IR level stack protector pass to decide if a stack
       protector is required/which BB we insert the stack protector check
       in by reusing the logic already therein. If we wish to generate a
       stack protector check in a basic block, we place a special IR
       intrinsic called llvm.stackprotectorcheck right before the BB's
       returninst or if there is a callinst that could potentially be
       sibling call optimized, before the call inst.

    b. Then when a BB with said intrinsic is processed, we codegen the BB
       normally via SelectBasicBlock. In said process, when we visit the
       stack protector check, we do not actually emit anything into the
       BB. Instead, we just initialize the stack protector descriptor
       class (which involves stashing information/creating the success
       mbbb and the failure mbb if we have not created one for this
       function yet) and export the guard variable that we are going to
       compare.

    c. After we finish selecting the basic block, in FinishBasicBlock if
       the StackProtectorDescriptor attached to the SelectionDAGBuilder is
       initialized, we first find a splice point in the parent basic block
       before the terminator and then splice the terminator of said basic
       block into the success basic block. Then we code-gen a new tail for
       the parent basic block consisting of the two loads, the comparison,
       and finally two branches to the success/failure basic blocks. We
       conclude by code-gening the failure basic block if we have not
       code-gened it already (all stack protector checks we generate in
       the same function, use the same failure basic block).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188755 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-20 07:00:16 +00:00
autoconf Recognize NetBSD's terminfo implementation. 2013-08-17 11:06:00 +00:00
bindings We're in 3.4 land now. 2013-05-07 20:31:28 +00:00
cmake Suppress an annoying CMake warning in ChooseMSVCCRT.cmake 2013-08-19 20:25:26 +00:00
docs Add a llvm.copysign intrinsic 2013-08-19 23:35:46 +00:00
examples ExceptionDemo.cpp: Tweak a @param. [-Wdocumentation] 2013-07-29 11:03:50 +00:00
include Add a llvm.copysign intrinsic 2013-08-19 23:35:46 +00:00
lib Teach selectiondag how to handle the stackprotectorcheck intrinsic. 2013-08-20 07:00:16 +00:00
projects Port the detection of zlib from the main autoconf system to the sample 2013-08-18 01:55:15 +00:00
runtime Use @rpath for libraries rather than @executable_path on OSX. 2013-08-02 01:51:52 +00:00
test Marking MCJIT PIC tests as XFAIL on AArch64 2013-08-20 01:50:50 +00:00
tools llvm-symbolizer: add support for .gnu_debuglink section 2013-08-14 17:09:30 +00:00
unittests Introduce SpecialCaseList::isIn overload for GlobalAliases. 2013-08-19 19:00:35 +00:00
utils [lit] Rewrite TODO list, and elaborate on some things. 2013-08-16 23:30:23 +00:00
.arcconfig Add .arcconfig to the repository. Useful if someone wants to use phabricator's command line tool. 2012-12-01 12:07:58 +00:00
.gitignore Add extra vim swap file pattern 2012-10-09 23:48:34 +00:00
CMakeLists.txt CMake: polish the Windows packaging rules 2013-08-15 23:44:31 +00:00
CODE_OWNERS.TXT Add more owners to CODE_OWNERS.TXT (Kostya Serebryany: AddressSanitizer and ThreadSanitizer; Evgeniy Stepanov: MemorySanitizer) 2013-06-27 08:47:12 +00:00
configure Recognize NetBSD's terminfo implementation. 2013-08-17 11:06:00 +00:00
CREDITS.TXT Test commit. 2013-08-16 18:09:06 +00:00
LICENSE.TXT Be more specific and capitalize filenames. 2013-05-21 21:22:34 +00:00
llvm.spec.in Tidy up. s/Low Level Virtual Machine/LLVM/. 2012-01-25 22:00:23 +00:00
LLVMBuild.txt LLVMBuild: Introduce a common section which currently has a list of the 2011-12-12 22:45:54 +00:00
Makefile Fix regular expression used by 'make update' to only look for 'I' and '?' at the start of svn info results and to check for spaces after 'I' instead of just after '?'. 2013-07-03 14:48:37 +00:00
Makefile.common Makefile.common: Update a description, s/Source/SOURCES/ , according to MakefileGuide.html#control-variables . 2012-12-07 01:43:23 +00:00
Makefile.config.in Add an autoconf option for turning on -gsplit-dwarf by default 2013-06-25 01:12:25 +00:00
Makefile.rules Makefile.rules: Avoid -fomit-frame-pointer also on cygwin due to PR14646. 2013-08-18 03:38:40 +00:00
README.txt test 2013-04-17 05:34:03 +00:00

Low Level Virtual Machine (LLVM)
================================

This directory and its subdirectories contain source code for the Low Level
Virtual Machine, a toolkit for the construction of highly optimized compilers,
optimizers, and runtime environments.

LLVM is open source software. You may freely distribute it under the terms of
the license agreement found in LICENSE.txt.

Please see the documentation provided in docs/ for further
assistance with LLVM, and in particular docs/GettingStarted.rst for getting
started with LLVM and docs/README.txt for an overview of LLVM's
documentation setup.

If you're writing a package for LLVM, see docs/Packaging.rst for our
suggestions.