| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
form.
Summary:
GetTarget() may modify TripleName without also updating TheTriple.
This can lead to situations where the MCObjectStreamer has a different triple
to the rest of LLVM.
This inconsistency caused sparc-little-endian.s to pass on Windows because most
of LLVM had sparcel-pc-win32 while MCObjectStreamer had "". I believe the same
kind of thing was also true of Darwin.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin, rafael
Differential Revision: http://reviews.llvm.org/D10450
llvm-svn: 239808
|
|
|
|
|
|
|
| |
The successors cache is now a local variable, making it more visible that it
is only valid for the MBB being processed.
llvm-svn: 239807
|
|
|
|
|
|
|
| |
review:
http://reviews.llvm.org/D10439
llvm-svn: 239806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Investigating.
The emission was as below;
---
name: foo
alignment: 31428584
exposesReturnsTwice: true
hasInlineAsm: false
...
---
name: bar
alignment: 1701667182
exposesReturnsTwice: false
hasInlineAsm: false
...
---
name: func
alignment: 8
exposesReturnsTwice: false
hasInlineAsm: false
...
---
name: func2
alignment: 16
exposesReturnsTwice: true
hasInlineAsm: true
...
llvm-svn: 239805
|
|
|
|
| |
llvm-svn: 239804
|
|
|
|
|
|
|
|
|
| |
We were propagating the coverage map into the body of an if statement,
but not into the condition thereafter. This is fine as long as the two
locations are in the same virtual file, but they won't be when the
"if" part of the statement is from a macro and the condition is not.
llvm-svn: 239803
|
|
|
|
|
|
|
|
|
| |
When we multiply two 64-bit vectors, we extract lower and upper part and use the PMULUDQ instruction.
When one of the operands is a constant, the upper part may be zero, we know this at compile time.
Example: %a = mul <4 x i64> %b, <4 x i64> < i64 5, i64 5, i64 5, i64 5>.
I'm checking the value of the upper part and prevent redundant "multiply", "shift" and "add" operations.
llvm-svn: 239802
|
|
|
|
| |
llvm-svn: 239801
|
|
|
|
|
|
| |
I forgot to update some clang test cases. I'll fix and resubmit tomorrow.
llvm-svn: 239800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are really immediate DUPs, and suffer from the same problem
with long instructions with a high/2 variant (e.g. smull).
By extending a MOVI (or DUP, before this patch), we can avoid an ext
on the other operand of the long instruction, e.g. turning:
ext.16b v0, v0, v0, #8
movi.4h v1, #0x53
smull.4s v0, v0, v1
into:
movi.8h v1, #0x53
smull2.4s v0, v0, v1
While there, add a now-necessary combine to fold (VT NVCAST (VT x)).
llvm-svn: 239799
|
|
|
|
| |
llvm-svn: 239798
|
|
|
|
|
|
|
|
| |
This change is hopefully NFC. The only tricky part is that I changed the context instruction being used to the branch rather than the comparison. I believe both to be correct, but the branch is strictly more powerful. With the moved code, using the branch instruction is required for the basic block comparison test to return the same result. The previous code was able to directly access both the branch and the comparison where the revised code is not.
Differential Revision: http://reviews.llvm.org/D9652
llvm-svn: 239797
|
|
|
|
|
|
|
|
|
| |
`LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td`
needs to regenerate `Instrinsics.h` before anyone can include anything
from the LLVM_IR module. Represent the dependency explicitly to prevent
that.
llvm-svn: 239796
|
|
|
|
|
|
|
|
| |
If a parameter to a function is known non-null, use the existing parameter attributes to record that fact at the call site. This has no optimization benefit by itself - that I know of - but is an enabling change for http://reviews.llvm.org/D9129.
Differential Revision: http://reviews.llvm.org/D9132
llvm-svn: 239795
|
|
|
|
|
|
|
| |
Mark CodeGen/DIEValues.def as a textual inclusion to fix the
`LLVM_ENABLE_MODULES` build.
llvm-svn: 239794
|
|
|
|
|
|
|
|
| |
Fix a build failure with `LLVM_ENABLE_MODULES` due to
`ProfileData::instr` conflicting with a function `instr()` in
`<curses.h>`.
llvm-svn: 239793
|
|
|
|
|
|
| |
-fno-module-maps). The old names are preserved for compatibility.
llvm-svn: 239792
|
|
|
|
| |
llvm-svn: 239791
|
|
|
|
|
|
|
|
|
|
|
| |
This commit serializes the simple, scalar attributes from the
'MachineFunction' class.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10449
llvm-svn: 239790
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
llvm-svn: 239789
|
|
|
|
|
|
|
|
|
| |
This commit decouples the MIR printer and the MIR printing pass so
that it will be possible to move the MIR printer into a separate
machine IR library later on.
Reviewers: Duncan P. N. Exon Smith
llvm-svn: 239788
|
|
|
|
|
|
|
| |
These driver options never did anything (they weren't forwarded to the
frontend). Also update the documentation to not mention them.
llvm-svn: 239787
|
|
|
|
| |
llvm-svn: 239786
|
|
|
|
|
|
| |
Hopefully the last partial revert. Sorry about the noise.
llvm-svn: 239785
|
|
|
|
|
|
| |
expanded in OpenMP pragmas. This patch adds support for that in -E.
llvm-svn: 239784
|
|
|
|
| |
llvm-svn: 239783
|
|
|
|
|
|
| |
Saves some typing and if someone wants to change them it makes it much easier.
llvm-svn: 239782
|
|
|
|
|
|
| |
rdar://problem/20571359
llvm-svn: 239781
|
|
|
|
|
|
|
|
| |
This is a prerequisite for turning on ODR type uniquing for ObjC++.
rdar://problem/21377883
llvm-svn: 239780
|
|
|
|
|
|
|
|
|
|
| |
out early
There are other characters we could optimize for (any non-letter pretty much), but keyword.iskeyword() will handle them, whereas quotes do have the potential to confuse us, so they actually need custom handling
Fixes rdar://problem/21022787
llvm-svn: 239779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM IR.
This commit creates a dummy LLVM IR function with one basic block and an unreachable
instruction for each parsed machine function when the MIR file doesn't have LLVM IR.
This change is required as the machine function analysis pass creates machine
functions only for the functions that are defined in the current LLVM module.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10135
llvm-svn: 239778
|
|
|
|
|
|
| |
rdar://21299888
llvm-svn: 239777
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit reports an error when the MIR parser encounters a machine
function with the name that is the same as the name of a different
machine function.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10130
llvm-svn: 239774
|
|
|
|
| |
llvm-svn: 239773
|
|
|
|
|
|
|
| |
constants in commented-out part of LLVMAttribute enum. Add tests that verify
that the safestack attribute is only allowed as a function attribute.
llvm-svn: 239772
|
|
|
|
| |
llvm-svn: 239771
|
|
|
|
| |
llvm-svn: 239770
|
|
|
|
|
|
| |
offset of the relocation. Set relocation addend and check it's correct in the ELF.
llvm-svn: 239769
|
|
|
|
|
|
| |
This reverts commit r239764 and the TestCases/Windows part of r239754.
llvm-svn: 239768
|
|
|
|
| |
llvm-svn: 239767
|
|
|
|
|
|
|
|
| |
target.env-vars would cause LLDB to crash
Fixes rdar://problem/21241817
llvm-svn: 239766
|
|
|
|
|
|
| |
would collide
llvm-svn: 239765
|
|
|
|
| |
llvm-svn: 239764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compiler-rt runtime support library
This patch adds runtime support for the Safe Stack protection to compiler-rt
(see http://reviews.llvm.org/D6094 for the detailed description of the
Safe Stack).
This patch is our implementation of the safe stack on top of compiler-rt. The
patch adds basic runtime support for the safe stack to compiler-rt that
manages unsafe stack allocation/deallocation for each thread.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6096
llvm-svn: 239763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang command line option and function attribute
This patch adds the -fsanitize=safe-stack command line argument for clang,
which enables the Safe Stack protection (see http://reviews.llvm.org/D6094
for the detailed description of the Safe Stack).
This patch is our implementation of the safe stack on top of Clang. The
patches make the following changes:
- Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang
to control safe stack usage (the safe stack is disabled by default).
- Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be
used to disable the safe stack for individual functions even when enabled
globally.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6095
llvm-svn: 239762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).
The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.
Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.
This patch is our implementation of the safe stack on top of LLVM. The
patches make the following changes:
- Add the safestack function attribute, similar to the ssp, sspstrong and
sspreq attributes.
- Add the SafeStack instrumentation pass that applies the safe stack to all
functions that have the safestack attribute. This pass moves all unsafe local
variables to the unsafe stack with a separate stack pointer, whereas all
safe variables remain on the regular stack that is managed by LLVM as usual.
- Invoke the pass as the last stage before code generation (at the same time
the existing cookie-based stack protector pass is invoked).
- Add unit tests for the safe stack.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6094
llvm-svn: 239761
|
|
|
|
| |
llvm-svn: 239760
|
|
|
|
| |
llvm-svn: 239759
|
|
|
|
|
|
|
|
| |
Switch to using BalancedDelimiterTracker to get better diagnostics for
unbalanced delimiters. This still does not handle any of the attributes, simply
improves the parsing.
llvm-svn: 239758
|
|
|
|
| |
llvm-svn: 239757
|