[CodeGen] Compute DT/LI lazily in SafeStackLegacyPass. NFC.

We currently require SCEV, which requires DT/LI. Those are expensive to
compute, but the pass only runs for functions that have the safes

[CodeGen] Compute DT/LI lazily in SafeStackLegacyPass. NFC.

We currently require SCEV, which requires DT/LI. Those are expensive to
compute, but the pass only runs for functions that have the safestack
attribute.

Compute DT/LI to build SCEV lazily, only when the pass is actually going
to transform the function.

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

llvm-svn: 302610

show more ...

[CodeGen] Split SafeStack into a LegacyPass and a utility. NFC.

This lets the pass focus on gathering the required analyzes, and the
utility class focus on the transformation.

Differential Revision

[CodeGen] Split SafeStack into a LegacyPass and a utility. NFC.

This lets the pass focus on gathering the required analyzes, and the
utility class focus on the transformation.

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

llvm-svn: 302609

show more ...

PR32382: Fix emitting complex DWARF expressions.

The DWARF specification knows 3 kinds of non-empty simple location
descriptions:
1. Register location descriptions
- describe a variable in a regis

PR32382: Fix emitting complex DWARF expressions.

The DWARF specification knows 3 kinds of non-empty simple location
descriptions:
1. Register location descriptions
- describe a variable in a register
- consist of only a DW_OP_reg
2. Memory location descriptions
- describe the address of a variable
3. Implicit location descriptions
- describe the value of a variable
- end with DW_OP_stack_value & friends

The existing DwarfExpression code is pretty much ignorant of these
restrictions. This used to not matter because we only emitted very
short expressions that we happened to get right by accident. This
patch makes DwarfExpression aware of the rules defined by the DWARF
standard and now chooses the right kind of location description for
each expression being emitted.

This would have been an NFC commit (for the existing testsuite) if not
for the way that clang describes captured block variables. Based on
how the previous code in LLVM emitted locations, DW_OP_deref
operations that should have come at the end of the expression are put
at its beginning. Fixing this means changing the semantics of
DIExpression, so this patch bumps the version number of DIExpression
and implements a bitcode upgrade.

There are two major changes in this patch:

I had to fix the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.

When lowering a DBG_VALUE, the decision of whether to emit a register
location description or a memory location description depends on the
MachineLocation — register machine locations may get promoted to
memory locations based on their DIExpression. (Future) optimization
passes that want to salvage implicit debug location for variables may
do so by appending a DW_OP_stack_value. For example:
DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8
DBG_VALUE, RAX --> DW_OP_reg0 +0
DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0

All testcases that were modified were regenerated from clang. I also
added source-based testcases for each of these to the debuginfo-tests
repository over the last week to make sure that no synchronized bugs
slip in. The debuginfo-tests compile from source and run the debugger.

https://bugs.llvm.org/show_bug.cgi?id=32382
<rdar://problem/31205000>

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

llvm-svn: 300522

show more ...

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 ty

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.

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

llvm-svn: 299949

show more ...

Revert "Turn some C-style vararg into variadic templates"

This reverts commit r299925 because it broke the buildbots. See e.g.
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008

ll

Revert "Turn some C-style vararg into variadic templates"

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

show more ...

Turn some C-style vararg into variadic templates

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr

Turn some C-style vararg into variadic templates

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

show more ...

Revert "Turn some C-style vararg into variadic templates"

This reverts commit r299699, the examples needs to be updated.

llvm-svn: 299702

Turn some C-style vararg into variadic templates

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr

Turn some C-style vararg into variadic templates

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

show more ...

Test commit.

llvm-svn: 284411

[safestack] Use non-thread-local unsafe stack pointer for Contiki OS

Patch by Michael LeMay

Differential revision: http://reviews.llvm.org/D19852

llvm-svn: 284254

[safestack] Reapply r283248 after moving X86-targeted SafeStack tests into
the X86 subdirectory. Original commit message:

Requires a valid TargetMachine to be passed to the SafeStack pass.

Patch by

[safestack] Reapply r283248 after moving X86-targeted SafeStack tests into
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

show more ...

Turn cl::values() (for enum) from a vararg function to using C++ variadic template

The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when c

Turn cl::values() (for enum) from a vararg function to using C++ variadic 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

show more ...

Revert r283248. It caused failures in the hexagon buildbots.

llvm-svn: 283254

[safestack] Requires a valid TargetMachine to be passed to the SafeStack pass.

Patch by Michael LeMay

Differential revision: http://reviews.llvm.org/D24896

llvm-svn: 283248

[safestack] Fix stack guard live range.

Stack guard slot is live throughout the function.

llvm-svn: 276712

StackColoring for SafeStack.

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 n

StackColoring for SafeStack.

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

show more ...

Fix doubly included header

llvm-svn: 273528

[safestack] Sink unsafe address computation to each use.

This is a fix for PR27844.
When replacing uses of unsafe allocas, emit the new location
immediately after each use. Without this, the pointer

[safestack] Sink unsafe address computation to each use.

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

show more ...

[safestack] Fixup llvm.dbg.value when rewriting unsafe allocas.

When moving unsafe allocas to the unsafe stack, dbg.declare intrinsics are
updated to refer to the new location.

This change does the

[safestack] Fixup llvm.dbg.value when rewriting unsafe allocas.

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

show more ...

[safestack] Add canary to unsafe stack frames

Add StackProtector to SafeStack. This adds limited protection against
data corruption in the caller frame. Current implementation treats
all stack prote

[safestack] Add canary to unsafe stack frames

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

show more ...

[safestack] Make sure the unsafe stack pointer is popped in all cases

The unsafe stack pointer is only popped in moveStaticAllocasToUnsafeStack so it won't happen if there are no static allocas.

Fi

[safestack] Make sure the unsafe stack pointer is popped in all cases

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

show more ...

Move SafeStack to CodeGen.

It depends on the target machinery, that's not available for
instrumentation passes.

llvm-svn: 258942