| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
includes.
llvm-svn: 172891
|
| |
|
|
| |
llvm-svn: 172813
|
| |
|
|
| |
llvm-svn: 172806
|
| |
|
|
|
|
| |
the values of shadow scale and offset to the runtime
llvm-svn: 172709
|
| |
|
|
|
|
| |
passes. Add test for non-default mapping scale and offset. No functionality change
llvm-svn: 172610
|
| |
|
|
|
|
| |
Also improve test coveration of the handling of relational comparisons.
llvm-svn: 172539
|
| |
|
|
|
|
|
|
|
| |
This fixes va_start/va_copy of a va_list field which happens to not
be laid out at a 16-byte boundary.
Differential Revision: http://llvm-reviews.chandlerc.com/D276
llvm-svn: 172128
|
| |
|
|
|
|
|
|
|
|
| |
code that includes Intrinsics.gen directly.
This never showed up in my testing because the old Intrinsics.gen was
still kicking around in the make build system and was correct there. =[
Thankfully, some of the bots to clean rebuilds and that caught this.
llvm-svn: 171373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
| |
|
|
|
|
|
|
|
|
| |
utils/sort_includes.py script.
Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since the last time I sorted the
includes.
llvm-svn: 171362
|
| |
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171253
|
| |
|
|
| |
llvm-svn: 171183
|
| |
|
|
|
|
| |
it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments
llvm-svn: 171153
|
| |
|
|
|
|
|
| |
Origin alignment is as high as the alignment of the corresponding application
location, but never less than 4.
llvm-svn: 171110
|
| |
|
|
| |
llvm-svn: 171109
|
| |
|
|
|
|
|
| |
VectorType::getInteger() can not be used with them, because pointer size
depends on the target.
llvm-svn: 171070
|
| |
|
|
| |
llvm-svn: 171069
|
| |
|
|
|
|
| |
consistency
llvm-svn: 171061
|
| |
|
|
| |
llvm-svn: 171060
|
| |
|
|
|
|
|
|
|
| |
When the backend is used from clang, it should produce proper diagnostics
instead of just printing messages to errs(). Other clients may also want to
register their own error handlers with the LLVMContext, and the same handler
should work for warnings in the same way as the existing emitError methods.
llvm-svn: 171041
|
| |
|
|
| |
llvm-svn: 170902
|
| |
|
|
| |
llvm-svn: 170883
|
| |
|
|
| |
llvm-svn: 170544
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changes adds shadow and origin propagation for unknown intrinsics
by examining the arguments and ModRef behaviour. For now, only 3 classes
of intrinsics are handled:
- those that look like simple SIMD store
- those that look like simple SIMD load
- those that don't have memory effects and look like arithmetic/logic/whatever
operation on simple types.
llvm-svn: 170530
|
| |
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
| |
|
|
| |
llvm-svn: 170404
|
| |
|
|
| |
llvm-svn: 170347
|
| |
|
|
| |
llvm-svn: 170203
|
| |
|
|
|
|
| |
Origin address is always 4 byte aligned, and the access type is always i32.
llvm-svn: 170199
|
| |
|
|
|
|
|
|
| |
This change moves the code for default shadow propagaition (handleShadowOr)
and origin tracking (setOriginForNaryOp) into a new builder-like class. Also
gets rid of handleShadowOrBinary.
llvm-svn: 170192
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When ASan replaces <alloca instruction> with
<offset into a common large alloca>, it should also patch
llvm.dbg.declare calls and replace debug info descriptors to mark
that we've replaced alloca with a value that stores an address
of the user variable, not the user variable itself.
See PR11818 for more context.
llvm-svn: 169984
|
| |
|
|
|
|
|
|
| |
Use explicitely aligned store and load instructions to deal with argument and
retval shadow. This matters when an argument's alignment is higher than
__msan_param_tls alignment (which is the case with __m128i).
llvm-svn: 169859
|
| |
|
|
|
|
|
|
|
| |
The `-mno-red-zone' flag wasn't being propagated to the functions that code
coverage generates. This allowed some of them to use the red zone when that
wasn't allowed.
<rdar://problem/12843084>
llvm-svn: 169754
|
| |
|
|
|
|
| |
in the near future.
llvm-svn: 169651
|
| |
|
|
|
|
|
|
|
|
| |
MSan uses a TLS slot to pass shadow for function arguments and return values.
This makes all instrumented functions not readonly, and at the same time
requires that all callees of an instrumented function that may be
MSan-instrumented do not have readonly attribute (otherwise some of the
instrumentation may be optimized out).
llvm-svn: 169591
|
| |
|
|
| |
llvm-svn: 169504
|
| |
|
|
| |
llvm-svn: 169491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of unconditionally storing origin with every application store,
only do this when the shadow of the stored value is != 0.
This change also delays instrumentation of stores until after the walk over
function's instructions, because adding new basic blocks confuses InstVisitor.
We only keep 1 origin value per 4 bytes of application memory. This change
fixes the bug when a store of a single clean byte wiped the origin for the
whole 4-byte area.
Since stores of uninitialized values are relatively uncommon, this change
improves performance of track-origins mode by 5% median and by up to 47% on
specs.
llvm-svn: 169490
|
| |
|
|
| |
llvm-svn: 169383
|
| |
|
|
|
|
| |
This mirrors the change in ASan & TSan done in r168864.
llvm-svn: 169378
|
| |
|
|
|
|
|
| |
LinkOnceODRLinkage globals may be removed in GlobalOpt if not used in the
current module.
llvm-svn: 169377
|
| |
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
| |
|
|
|
|
| |
does not change the current behavior)
llvm-svn: 169216
|
| |
|
|
|
|
| |
emit calls into runtime library that poison memory for local variables when their lifetime is over and unpoison memory when their lifetime begins.
llvm-svn: 169200
|
| |
|
|
| |
llvm-svn: 169143
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
| |
llvm-svn: 169119
|
| |
|
|
| |
llvm-svn: 168995
|
| |
|
|
|
|
|
|
|
|
|
|
| |
depends on the IR infrastructure, there is no sense in it being off in
Support land.
This is in preparation to start working to expand InstVisitor into more
special-purpose visitors that are still generic and can be re-used
across different passes. The expansion will go into the Analylis tree
though as nothing in VMCore needs it.
llvm-svn: 168972
|
| |
|
|
|
|
| |
the module is blacklisted.
llvm-svn: 168913
|