| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 175568
|
| |
|
|
| |
llvm-svn: 175567
|
| |
|
|
| |
llvm-svn: 175565
|
| |
|
|
| |
llvm-svn: 175562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
Also, call these two new functions in memset/memcpy
instrumentation.
asan-rt part will follow.
llvm-svn: 175507
|
| |
|
|
| |
llvm-svn: 175476
|
| |
|
|
|
|
| |
library call.
llvm-svn: 175470
|
| |
|
|
|
|
| |
long double will require a more general solution
llvm-svn: 175442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR15289. This bug was introduced (recently) in r175215; collecting
all std::vector references for candidate pairs to delete at once is invalid
because subsequent lookups in the owning DenseMap could invalidate the
references.
bugpoint was able to reduce a useful test case. Unfortunately, because whether
or not this asserts depends on memory layout, this test case will sometimes
appear to produce valid output. Nevertheless, running under valgrind will
reveal the error.
llvm-svn: 175397
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(or (bool?A:B),(bool?C:D)) --> (bool?(or A,C):(or B,D))
By the time the OR is visited, both the SELECTs have been visited and not
optimized and the OR itself hasn't been transformed so we do this transform in
the hopes that the new ORs will be optimized.
The transform is explicitly disabled for vector-selects until "codegen matures
to handle them better".
Patch by Muhammad Tauqir!
llvm-svn: 175380
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 175364
|
| |
|
|
|
|
|
|
|
|
| |
Several functions and variable names used the term 'tree' to refer
to what is actually a DAG. Correcting this mistake will, hopefully,
prevent confusion in the future.
No functionality change intended.
llvm-svn: 175278
|
| |
|
|
|
|
| |
types..."
llvm-svn: 175273
|
| |
|
|
|
|
|
|
|
| |
It enables to work with a smaller constant, which is target friendly for those which can compare to immediates.
It also avoids inserting a shift in favor of a trunc, which can be free on some targets.
This used to work until LLVM-3.1, but regressed with the 3.2 release.
llvm-svn: 175270
|
| |
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=151
llvm-svn: 175266
|
| |
|
|
|
|
| |
linkage.
llvm-svn: 175264
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some basic blocks, it is possible to generate many candidate pairs for
relatively few pairable instructions. When many (tens of thousands) of these pairs
are generated for a single instruction group, the time taken to generate and
rank the different vectorization plans can become quite large. As a result, we now
cap the number of candidate pairs within each instruction group. This is done by
closing out the group once the threshold is reached (set now at 3000 pairs).
Although this will limit the overall compile-time impact, this may not be the best
way to achieve this result. It might be better, for example, to prune excessive
candidate pairs after the fact the prevent the generation of short, but highly-connected
groups. We can experiment with this in the future.
This change reduces the overall compile-time slowdown of the csa.ll test case in
PR15222 to ~5x. If 5x is still considered too large, a lower limit can be
used as the default.
This represents a functionality change, but only for very large inputs
(thus, there is no regression test).
llvm-svn: 175251
|
| |
|
|
|
|
|
|
|
|
| |
All instances of std::multimap have now been replaced by
DenseMap<K, std::vector<V> >, and this yields a speedup of 5% on the
csa.ll test case from PR15222.
No functionality change intended.
llvm-svn: 175216
|
| |
|
|
|
|
|
|
|
|
| |
This is another commit on the road to removing std::multimap from
BBVectorize. This gives an ~1% speedup on the csa.ll test case
in PR15222.
No functionality change intended.
llvm-svn: 175215
|
| |
|
|
|
|
|
|
|
| |
It's possible (e.g. after an LTO build) that an internal global may be used for
debugging purposes. If that's the case appending a '.b' to it makes it hard to
find that variable. Steal the name from the old GV before deleting it so that
they can find that variable again.
llvm-svn: 175104
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 175076
|
| |
|
|
|
|
|
|
| |
metadata is the loop vectorizer.
See the documentation update for more info.
llvm-svn: 175060
|
| |
|
|
| |
llvm-svn: 175033
|
| |
|
|
|
|
| |
visitSExt is an adapted copy of the related visitZExt method, so adapt the comment accordingly.
llvm-svn: 175019
|
| |
|
|
| |
llvm-svn: 175017
|
| |
|
|
|
|
| |
trying to do.
llvm-svn: 175014
|
| |
|
|
|
|
| |
avoid a second pred_iterator traversal.
llvm-svn: 175001
|
| |
|
|
|
|
|
| |
(through a loop), don't continue to iterate through the reamining
predecessors.
llvm-svn: 174994
|
| |
|
|
|
|
| |
for tidiness' sake.
llvm-svn: 174988
|
| |
|
|
| |
llvm-svn: 174985
|
| |
|
|
|
|
| |
may get mapped at 0x100000000+ and thus may interleave with the shadow.
llvm-svn: 174964
|
| |
|
|
|
|
| |
roughly 5% speedup. Since this is an ABI change, bump the asan ABI version by renaming __asan_init to __asan_init_v1. llvm part, compiler-rt part will follow
llvm-svn: 174957
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When building the pairable-instruction dependency map, don't search
past the last pairable instruction. For large blocks that have been
divided into multiple instruction groups, searching past the last
instruction in each group is very wasteful. This gives a 32% speedup
on the csa.ll test case from PR15222 (when using 50 instructions
in each group).
No functionality change intended.
llvm-svn: 174915
|
| |
|
|
|
|
|
|
|
|
|
| |
This map is queried only for instructions in pairs of pairable
instructions; so make sure that only pairs of pairable
instructions are added to the map. This gives a 3.5% speedup
on the csa.ll test case from PR15222.
No functionality change intended.
llvm-svn: 174914
|
| |
|
|
|
|
| |
bitcast X to ...
llvm-svn: 174905
|
| |
|
|
|
|
|
|
|
|
| |
This eliminates one more linear search over a range of
std::multimap entries. This gives a 22% speedup on the
csa.ll test case from PR15222.
No functionality change intended.
llvm-svn: 174893
|
| |
|
|
|
|
|
|
|
|
| |
This flag makes asan use a small (<2G) offset for 64-bit asan shadow mapping.
On x86_64 this saves us a register, thus achieving ~2/3 of the
zero-base-offset's benefits in both performance and code size.
Thanks Jakub Jelinek for the idea.
llvm-svn: 174886
|
| |
|
|
|
|
|
|
|
| |
This removes the last of the linear searches over ranges of std::multimap
iterators, giving a 7% speedup on the doduc.bc input from PR15222.
No functionality change intended.
llvm-svn: 174859
|
| |
|
|
|
|
|
|
|
| |
This is another cleanup aimed at eliminating linear searches
in ranges of std::multimap.
No functionality change intended.
llvm-svn: 174858
|
| |
|
|
|
|
|
|
|
|
| |
Profiling suggests that getInstructionTypes is performance-sensitive,
this cleans up some double-casting in that function in favor of
using dyn_cast.
No functionality change intended.
llvm-svn: 174857
|
| |
|
|
|
|
|
|
|
|
|
| |
By itself, this does not have much of an effect, but only because in the default
configuration the full cycle checks are used only for small problem sizes.
This is part of a general cleanup of uses of iteration over std::multimap
ranges only for the purpose of checking membership.
No functionality change intended.
llvm-svn: 174856
|
| |
|
|
|
|
|
|
|
| |
Handle chains in which the same offset is used for both loads and
stores to the same array.
Fixes rdar://11410078.
llvm-svn: 174789
|
| |
|
|
| |
llvm-svn: 174786
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/12867368>"
This reverts r171041. This was a nice idea that didn't work out well.
Clang warnings need to be associated with warning groups so that they can
be selectively disabled, promoted to errors, etc. This simplistic patch didn't
allow for that. Enhancing it to provide some way for the backend to specify
a front-end warning type seems like overkill for the few uses of this, at
least for now.
llvm-svn: 174748
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to the cost-model change in r174713 which splits
the cost of a memory operation between the address computation and the
actual memory access. In r174713, this cost is always added to the
memory operation cost, and so BBVectorize will do the same.
Currently, this new cost function is used only by ARM, and I don't
have any ARM test cases for BBVectorize. Assistance in generating some
good ARM test cases for BBVectorize would be greatly appreciated!
llvm-svn: 174743
|
| |
|
|
|
|
|
|
| |
isn't using the default calling convention. However, if the transformation is
from a call to inline IR, then the calling convention doesn't matter.
rdar://13157990
llvm-svn: 174724
|
| |
|
|
| |
llvm-svn: 174723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a function to target transform info to query for the cost of address
computation. The cost model analysis pass now also queries this interface.
The code in LoopVectorize adds the cost of address computation as part of the
memory instruction cost calculation. Only there, we know whether the instruction
will be scalarized or not.
Increase the penality for inserting in to D registers on swift. This becomes
necessary because we now always assume that address computation has a cost and
three is a closer value to the architecture.
radar://13097204
llvm-svn: 174713
|
| |
|
|
| |
llvm-svn: 174709
|
| |
|
|
|
|
|
|
|
|
| |
included."
This reverts commit 3854a5d90fee52af1065edbed34521fff6cdc18d.
This causes a clang unit test to hang: vtable-available-externally.cpp.
llvm-svn: 174692
|