summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SafeStack.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-1/+1
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-111-1/+1
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-111-1/+1
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-061-2/+2
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
* Turn some C-style vararg into variadic templatesMehdi Amini2017-04-061-2/+2
| | | | | | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299699
* Test commit.Michael LeMay2016-10-171-1/+1
| | | | llvm-svn: 284411
* [safestack] Use non-thread-local unsafe stack pointer for Contiki OSDavid L Kreitzer2016-10-141-49/+1
| | | | | | | | Patch by Michael LeMay Differential revision: http://reviews.llvm.org/D19852 llvm-svn: 284254
* [safestack] Reapply r283248 after moving X86-targeted SafeStack tests intoDavid L Kreitzer2016-10-131-7/+6
| | | | | | | | | | | | the X86 subdirectory. Original commit message: Requires a valid TargetMachine to be passed to the SafeStack pass. Patch by Michael LeMay Differential revision: http://reviews.llvm.org/D24896 llvm-svn: 284161
* Turn cl::values() (for enum) from a vararg function to using C++ variadic ↵Mehdi Amini2016-10-081-2/+1
| | | | | | | | | | | | | | | template The core of the change is supposed to be NFC, however it also fixes what I believe was an undefined behavior when calling: va_start(ValueArgs, Desc); with Desc being a StringRef. Differential Revision: https://reviews.llvm.org/D25342 llvm-svn: 283671
* Revert r283248. It caused failures in the hexagon buildbots.David L Kreitzer2016-10-041-6/+7
| | | | llvm-svn: 283254
* [safestack] Requires a valid TargetMachine to be passed to the SafeStack pass.David L Kreitzer2016-10-041-7/+6
| | | | | | | | Patch by Michael LeMay Differential revision: http://reviews.llvm.org/D24896 llvm-svn: 283248
* [safestack] Fix stack guard live range.Evgeniy Stepanov2016-07-261-1/+1
| | | | | | Stack guard slot is live throughout the function. llvm-svn: 276712
* StackColoring for SafeStack.Evgeniy Stepanov2016-06-291-38/+50
| | | | | | | | | | | | | | | | This is a fix for PR27842. An IR-level implementation of stack coloring tailored to work with SafeStack. It is a bit weaker than the MI implementation in that it does not the "lifetime start at first access" logic. This can be improved in the future. This patch also replaces the naive implementation of stack frame layout with a greedy algorithm that can split existing stack slots and even fit small objects inside the alignment padding of other objects. llvm-svn: 274162
* Fix doubly included headerMatt Arsenault2016-06-231-1/+0
| | | | llvm-svn: 273528
* [safestack] Sink unsafe address computation to each use.Evgeniy Stepanov2016-06-161-8/+31
| | | | | | | | | | This is a fix for PR27844. When replacing uses of unsafe allocas, emit the new location immediately after each use. Without this, the pointer stays live from the function entry to the last use, while it's usually cheaper to recalculate. llvm-svn: 272969
* [safestack] Fixup llvm.dbg.value when rewriting unsafe allocas.Evgeniy Stepanov2016-06-161-0/+1
| | | | | | | | | When moving unsafe allocas to the unsafe stack, dbg.declare intrinsics are updated to refer to the new location. This change does the same to dbg.value intrinsics. llvm-svn: 272968
* [safestack] Add canary to unsafe stack framesEvgeniy Stepanov2016-04-111-19/+76
| | | | | | | | Add StackProtector to SafeStack. This adds limited protection against data corruption in the caller frame. Current implementation treats all stack protector levels as -fstack-protector-all. llvm-svn: 266004
* [safestack] Make sure the unsafe stack pointer is popped in all casesAnna Zaks2016-02-021-27/+26
| | | | | | | | | | The unsafe stack pointer is only popped in moveStaticAllocasToUnsafeStack so it won't happen if there are no static allocas. Fixes https://llvm.org/bugs/show_bug.cgi?id=26122 Differential Revision: http://reviews.llvm.org/D16339 llvm-svn: 259447
* Move SafeStack to CodeGen.Benjamin Kramer2016-01-271-0/+760
It depends on the target machinery, that's not available for instrumentation passes. llvm-svn: 258942
OpenPOWER on IntegriCloud