| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
which requires TargetData.
llvm-svn: 163799
|
| |
|
|
|
|
|
|
|
|
| |
This function writes out the current values of the counters and then resets
them. This can be used similarly to the __gcov_flush function to sync the
counters when need be. For instance, in a situation where the application
doesn't exit.
<rdar://problem/12185886>
llvm-svn: 163757
|
| |
|
|
| |
llvm-svn: 163205
|
| |
|
|
|
|
| |
Reid Watson
llvm-svn: 163199
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the code guarded with ANDROIDEABI are not
ARM-specific, and having no relation with arm-eabi.
Thus, it will be more natural to call this
environment "Android" instead of "ANDROIDEABI".
Note: We are not using ANDROID because several projects
are using "-DANDROID" as the conditional compilation
flag.
llvm-svn: 163087
|
| |
|
|
| |
llvm-svn: 162907
|
| |
|
|
| |
llvm-svn: 162888
|
| |
|
|
|
|
| |
path.
llvm-svn: 162883
|
| |
|
|
|
|
|
|
| |
This lets the user run the program from a different directory and still have the
.gcda files show up in the correct place.
<rdar://problem/12179524>
llvm-svn: 162855
|
| |
|
|
| |
llvm-svn: 162851
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more severe
with the recent memory builtin improvements.
Since the memory builtin functions are used everywhere, this required passing
TLI in many places. This means that functions that now have an optional TLI
argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead
mallocs anymore if the TLI argument is missing. I've updated most passes to do
the right thing.
Fixes PR13694 and probably others.
llvm-svn: 162841
|
| |
|
|
|
|
| |
limited to functions any more
llvm-svn: 162566
|
| |
|
|
|
|
| |
modules. Patch by Reid Watson.
llvm-svn: 162565
|
| |
|
|
|
|
| |
strict weak ordering, and don't pass possibly-null pointers to dyn_cast.
llvm-svn: 162314
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
to handle unaligned partially OOB accesses. See http://code.google.com/p/address-sanitizer/issues/detail?id=100
llvm-svn: 161937
|
| |
|
|
|
|
| |
end of the function. This doesn't seem to fix or break anything, but is considered to be more friendly to downstream passes
llvm-svn: 161870
|
| |
|
|
|
|
| |
idea. (partly related to Bug 13225)
llvm-svn: 161757
|
| |
|
|
|
|
|
| |
original commit msg:
MemoryBuiltins: add support to determine the size of strdup'ed non-constant strings
llvm-svn: 160751
|
| |
|
|
|
|
| |
strings
llvm-svn: 160742
|
| |
|
|
|
|
| |
moved earlier. This fixes some layering issues.
llvm-svn: 160611
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
allows to hold performance experiments
llvm-svn: 160361
|
| |
|
|
|
|
| |
chandlerc, partially implemented crash callback merging (under flag)
llvm-svn: 160290
|
| |
|
|
|
|
| |
fully implemented yet, no functionality change except the BB order)
llvm-svn: 160284
|
| |
|
|
|
|
| |
on-demand
llvm-svn: 160269
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the move of *Builder classes into the Core library.
No uses of this builder in Clang or DragonEgg I could find.
If there is a desire to have an IR-building-support library that
contains all of these builders, that can be easily added, but currently
it seems likely that these add no real overhead to VMCore.
llvm-svn: 160243
|
| |
|
|
|
|
| |
(tsan issue #3). A unit test will follow separately.
llvm-svn: 159736
|
| |
|
|
| |
llvm-svn: 159522
|
| |
|
|
| |
llvm-svn: 159491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.
I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.
I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.
Thanks to Bill and Eric for giving the green light for this bit of cleanup.
llvm-svn: 159421
|
| |
|
|
|
|
| |
BB. This is (hopefully temporary) workaround for PR13225
llvm-svn: 159344
|
| |
|
|
|
|
|
|
|
| |
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.
The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.
llvm-svn: 159312
|
| |
|
|
| |
llvm-svn: 159112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the user/front-end to specify a model that is better
than what LLVM would choose by default. For example, a variable
might be declared as
@x = thread_local(initialexec) global i32 42
if it will not be used in a shared library that is dlopen'ed.
If the specified model isn't supported by the target, or if LLVM can
make a better choice, a different model may be used.
llvm-svn: 159077
|
| |
|
|
|
|
|
|
|
|
|
|
| |
inject some code in that will run via the "__mod_init_func" method that
registers the gcov "writeout" function to execute at exit time.
The problem is that the "__mod_term_func" method of specifying d'tors is
deprecated on Darwin. And it can lead to some ambiguities when dealing with
multiple libraries.
<rdar://problem/11110106>
llvm-svn: 157852
|
| |
|
|
| |
llvm-svn: 157683
|
| |
|
|
|
|
|
|
| |
replicating the code for every place it's needed, we instead generate a function
that does that for us. This function is local to the executable, so there
shouldn't be any writing violations.
llvm-svn: 157564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
are passed in. However, those arguments may be in a write-protected area, as far
as the runtime library is concerned. For instance, the data could be placed into
a 'linkedit' section, which isn't writable. Emit the code from
llvm_gcda_increment_indirect_counter directly into the function instead.
Note: The code for this is ugly, and can lead to bloat. We should look into
simplifying this code instead of having all of these branches.
<rdar://problem/11181370>
llvm-svn: 157505
|
| |
|
|
| |
llvm-svn: 157317
|
| |
|
|
| |
llvm-svn: 155986
|
| |
|
|
| |
llvm-svn: 155701
|
| |
|
|
| |
llvm-svn: 155698
|
| |
|
|
|
|
| |
the compiled source file.
llvm-svn: 155346
|
| |
|
|
| |
llvm-svn: 155341
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|