| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This became important after the recent move from ModulePass to FunctionPass because no cleanup is happening after asan pass any more.
llvm-svn: 166267
|
|
|
|
| |
llvm-svn: 165938
|
|
|
|
| |
llvm-svn: 165109
|
|
|
|
| |
llvm-svn: 165108
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
|
|
|
| |
llvm-svn: 164767
|
|
|
|
|
|
| |
sub-pass is off by default for now. Patch by Reid Watson. Note: this patch changes the interface between LLVM and compiler-rt parts of asan. The corresponding patch to compiler-rt will follow.
llvm-svn: 162268
|
|
|
|
|
|
| |
end of the function. This doesn't seem to fix or break anything, but is considered to be more friendly to downstream passes (test change)
llvm-svn: 161871
|
|
|
|
|
|
|
| |
original commit msg:
MemoryBuiltins: add support to determine the size of strdup'ed non-constant strings
llvm-svn: 160751
|
|
|
|
|
|
| |
strings
llvm-svn: 160742
|
|
|
|
|
|
|
|
| |
discussed 2 months ago or so.
Make sure we do not emit index computations with NSW flags so that we dont get an undef value if the GEP overflows
llvm-svn: 160589
|
|
|
|
|
|
|
|
| |
belongs. I dunno why in the world I dropped it in the Scalar folder in the first place.
No functionality change.
llvm-svn: 160587
|
|
|
|
|
|
| |
idea: insert an empty InlineAsm). Change the order in which the new BBs are inserted: the slow path BB is insert between old BBs, the crash BB is inserted at the end. Don't create an empty BB (introduced by recent commits). Update the test. The experimental code that does manual crash callback merge will most likely be deleted later.
llvm-svn: 160544
|
|
|
|
|
|
| |
fully implemented yet, no functionality change except the BB order)
llvm-svn: 160284
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that ASan relied on the at-the-end block insertion order to
(purely by happenstance) disable some LLVM optimizations, which in turn
start firing when the ordering is made more "normal". These
optimizations in turn merge many of the instrumentation reporting calls
which breaks the return address based error reporting in ASan.
We're looking at several different options for fixing this.
llvm-svn: 160256
|
|
|
|
|
|
|
|
|
| |
This is particularly useful to the backend code generators which try to
process things in the incoming function order.
Also, cleanup some uses of IRBuilder to be a bit simpler and more clear.
llvm-svn: 160254
|
|
|
|
|
|
|
|
|
|
|
| |
functionality test.
In general, unless the functionality is substantially separated, we
should lump more basic testing into this file. The test running
infrastructure likes having a few test files with more comprehensive
testing within them.
llvm-svn: 160253
|
|
|
|
| |
llvm-svn: 157683
|
|
|
|
| |
llvm-svn: 155698
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- don't isntrument reads from constant globals.
Saves ~1.5% of instrumented instructions on CPU2006
(counting static instructions, not their execution).
- don't insrument reads from vtable (which is a global constant too).
Saves ~5%.
I did not measure the run-time impact of this,
but it is certainly non-negative.
llvm-svn: 154444
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a write to the same temp follows in the same BB.
Also add stats printing.
On Spec CPU2006 this optimization saves roughly 4% of instrumented reads
(which is 3% of all instrumented accesses):
Writes : 161216
Reads : 446458
Reads-before-write: 18295
llvm-svn: 154418
|
|
|
|
|
|
| |
bug (forgot to return true after instrumenting); make sure the tsan tests are run
llvm-svn: 153448
|
|
|
|
|
|
| |
lit.local.cfg file
llvm-svn: 152567
|
|
|
|
|
|
|
|
| |
run with LIT now and now Dejagnu. dg.exp is no longer needed.
Patch reviewed by Daniel Dunbar. It will be followed by additional cleanup patches.
llvm-svn: 150664
|
|
|
|
|
|
| |
change)
llvm-svn: 150441
|
|
|
|
|
|
|
| |
Clang patch (flags) will follow shortly.
The run-time library will also follow, but not immediately.
llvm-svn: 150423
|
|
|
|
|
|
| |
llvm part
llvm-svn: 150102
|
|
|
|
|
|
|
|
|
| |
(GVN).
The problem initially reported by Mozilla folks (http://code.google.com/p/address-sanitizer/issues/detail?id=20),
but it also prevents us from enabling LLVM bootstrap with AddressSanitizer.
llvm-svn: 149925
|
|
|
|
| |
llvm-svn: 148846
|
|
|
|
|
|
| |
only once.
llvm-svn: 147509
|
|
|
|
| |
llvm-svn: 146718
|
|
|
|
| |
llvm-svn: 145092
|
|
|
|
|
|
| |
large chunks of inline assembler
llvm-svn: 144962
|
|
|
|
|
|
| |
asan; add a test check that asan does not touch linkonce_odr
llvm-svn: 144933
|
|
llvm-svn: 144758
|