| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This is a common pattern with dyn_cast and similar constructs, when the
PHI no longer depends on the select it can often be turned into a simpler
construct or even get hoisted out of the loop.
PR15340.
llvm-svn: 175995
|
|
|
|
| |
llvm-svn: 175994
|
|
|
|
| |
llvm-svn: 175964
|
|
|
|
| |
llvm-svn: 175898
|
|
|
|
|
|
|
| |
Listing all of the attributes for the callee of a call/invoke instruction is way
too much and makes the IR unreadable. Use references to attributes instead.
llvm-svn: 175877
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Storing the load/store instructions with the values
and inspect them using Alias Analysis to make sure
they don't alias, since the GEP pointer operand doesn't
take the offset into account.
Trying hard to not add any extra cost to loads and stores
that don't overlap on global values, AA is *only* calculated
if all of the previous attempts failed.
Using biggest vector register size as the stride for the
vectorization access, as we're being conservative and
the cost model (which calculates the real vectorization
factor) is only run after the legalization phase.
We might re-think this relationship in the future, but
for now, I'd rather be safe than sorry.
llvm-svn: 175818
|
|
|
|
|
|
|
|
|
|
|
| |
function attributes.
This makes the LLVM assembly look better. E.g.:
define void @foo() #0 { ret void }
attributes #0 = { nounwind noinline ssp }
llvm-svn: 175605
|
|
|
|
|
|
|
|
| |
considered as instructions with side effects.
rdar://13227456
llvm-svn: 175553
|
|
|
|
| |
llvm-svn: 175476
|
|
|
|
|
|
| |
library call.
llvm-svn: 175470
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Profiling tests *do* need a JIT. They'll pass if a cross-compiler targetting
AArch64 by default has been built, but fail if a native AArch64 compiler has
been build. Therefore XFAIL is inappropriate and we mark them unsupported.
ExecutionEngine tests are JIT by definition, they should also be unsupported.
Transforms/LICM only uses the interpreter to check the output is still sane
after optimisation. It can be switched to use an interpreter.
llvm-svn: 175433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
metadata, sorry.
llvm-svn: 175311
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 175252
|
|
|
|
|
|
| |
This reverts commit 58f20a3cbfca7384fe5e25e095f18572736a4792.
llvm-svn: 175249
|
|
|
|
|
|
| |
This reverts commit 997c6516ca161073a1d516ebca7c0ca7722f64e2.
llvm-svn: 175248
|
|
|
|
| |
llvm-svn: 175238
|
|
|
|
| |
llvm-svn: 175236
|
|
|
|
|
|
| |
'and' instructions. This is a pattern that shows up a lot in ubsan binaries.
llvm-svn: 175128
|
|
|
|
| |
llvm-svn: 175093
|
|
|
|
|
|
| |
bitcast X to ...
llvm-svn: 174905
|
|
|
|
| |
llvm-svn: 174903
|
|
|
|
| |
llvm-svn: 174865
|
|
|
|
|
|
|
|
|
| |
Handle chains in which the same offset is used for both loads and
stores to the same array.
Fixes rdar://11410078.
llvm-svn: 174789
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
included."
This reverts commit 3854a5d90fee52af1065edbed34521fff6cdc18d.
This causes a clang unit test to hang: vtable-available-externally.cpp.
llvm-svn: 174692
|
|
|
|
| |
llvm-svn: 174675
|
|
|
|
| |
llvm-svn: 174650
|
|
|
|
| |
llvm-svn: 174591
|
|
|
|
| |
llvm-svn: 174588
|
|
|
|
| |
llvm-svn: 174571
|
|
|
|
| |
llvm-svn: 174569
|
|
|
|
|
|
| |
platforms that are known to be missing them.
llvm-svn: 174564
|
|
|
|
|
|
| |
intrinsics, including ones on half types.
llvm-svn: 174555
|
|
|
|
| |
llvm-svn: 174438
|
|
|
|
| |
llvm-svn: 174433
|
|
|
|
|
|
| |
Found by running instcombine on a fabricated test case for the constant folder.
llvm-svn: 174430
|
|
|
|
|
|
| |
This was introduced in r173293.
llvm-svn: 174424
|
|
|
|
| |
llvm-svn: 174380
|
|
|
|
|
|
| |
requires +Asserts.
llvm-svn: 174379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the loop vectorizer cost model, we used to ignore stores/loads of a pointer
type when computing the widest type within a loop. This meant that if we had
only stores/loads of pointers in a loop we would return a widest type of 8bits
(instead of 32 or 64 bit) and therefore a vector factor that was too big.
Now, if we see a consecutive store/load of pointers we use the size of a pointer
(from data layout).
This problem occured in SingleSource/Benchmarks/Shootout-C++/hash.cpp (reduced
test case is the first test in vector_ptr_load_store.ll).
radar://13139343
llvm-svn: 174377
|
|
|
|
|
|
|
|
|
| |
externally_initialized return false for hasDefiniteInitializer and
hasUniqueInitializer.
rdar://12580965.
llvm-svn: 174345
|
|
|
|
|
|
|
|
|
|
| |
The main lists of debug info metadata attached to the compile_unit had an extra
layer of metadata nodes they went through for no apparent reason. This patch
removes that (& still passes just as much of the GDB 7.5 test suite). If anyone
can show evidence as to why these extra metadata nodes are there I'm open to
reverting this patch & documenting why they're there.
llvm-svn: 174266
|
|
|
|
| |
llvm-svn: 174210
|
|
|
|
|
|
|
|
|
|
| |
pointers too.
Prepare it for vectors of pointers and handle simple cases. We don't handle
complicated cases because accumulateConstantOffset bails on pointer vectors.
Fixes selfhost on i386.
llvm-svn: 174179
|
|
|
|
|
|
| |
transformation is illegal.
llvm-svn: 174156
|
|
|
|
| |
llvm-svn: 174152
|
|
|
|
|
|
|
|
|
|
|
|
| |
remaining use of AliasAnalysis concepts such as isIdentifiedObject to
prove pointer inequality.
@external_compare in test/Transforms/InstSimplify/compare.ll shows a simple
case where a noalias argument can be equal to a global variable address, and
while AliasAnalysis can get away with saying that these pointers don't alias,
instsimplify cannot say that they are not equal.
llvm-svn: 174122
|