| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 228615
|
| |
|
|
| |
llvm-svn: 228614
|
| |
|
|
|
|
|
| |
a) add gc attribute
b) remove unused param
llvm-svn: 228612
|
| |
|
|
|
|
|
|
|
|
| |
Without a valid data layout, deferenceable(N) doesn't get parsed or
propagated. Since this is the key item we are testing, add a dependency
on the pass.
Differential Revision: http://reviews.llvm.org/D7508
llvm-svn: 228611
|
| |
|
|
|
|
| |
This is just adding really simple tests which should have been part of the original submission. When doing so, I discovered that I'd mistakenly removed required pieces when preparing the patch for upstream submission. I fixed two such bugs in this submission.
llvm-svn: 228610
|
| |
|
|
| |
llvm-svn: 228609
|
| |
|
|
|
|
|
| |
I'll circle back and fix this somehow; for now I just don't want to
forget about it.
llvm-svn: 228608
|
| |
|
|
|
|
| |
These are never referenced or filled in.
llvm-svn: 228607
|
| |
|
|
|
|
|
|
|
|
| |
While a theoretical GC might change dereferenceability on collection,
there is no such known collector and no need to account for the case
with a flag yet.
Differential Revision: http://reviews.llvm.org/D7454
llvm-svn: 228606
|
| |
|
|
| |
llvm-svn: 228605
|
| |
|
|
|
|
|
|
|
|
| |
5 minutes is an eternity, so try to strike a better balance between
waiting long enough for any reasonable module build and not so long that
users kill the process because they think it's hanging.
Also give the client a way to delete the lock file after a timeout.
llvm-svn: 228603
|
| |
|
|
| |
llvm-svn: 228602
|
| |
|
|
| |
llvm-svn: 228598
|
| |
|
|
|
|
|
|
|
| |
Make use of the newly introduced inst_range to clean up two loops. Clean
up a third one while at it.
Differential Revision: http://reviews.llvm.org/D7455
llvm-svn: 228596
|
| |
|
|
|
|
|
| |
<NW> bit of a SCEVAddRecExpr does not depend on the sign of the step
and the start value of the step.
llvm-svn: 228595
|
| |
|
|
| |
llvm-svn: 228593
|
| |
|
|
| |
llvm-svn: 228587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a scev for sext({X,+,Y}), scev checks if the expression
is equivalent to {sext X,+,zext Y}. If it can prove that, it also
tags the original {X,+,Y} as <nsw>, which is not correct.
In the test case I run `-scalar-evolution` twice because the bug
manifests only once SCEV has run through and seen the `sext`
expressions (and then does a in-place mutation on {X,+,Y}).
Differential Revision: http://reviews.llvm.org/D7495
llvm-svn: 228586
|
| |
|
|
|
|
|
| |
As far as I can tell r228568 was the right workaround, and r228567 was
unnecessary. If reverting this causes problems on the bots I'll reinstate it.
llvm-svn: 228585
|
| |
|
|
| |
llvm-svn: 228581
|
| |
|
|
|
|
|
|
|
|
|
|
| |
veqv (vector equivalence)
vnand
vorc
I increased the AddedComplexity for these instructions to 500 to ensure they are generated instead of issuing other VSX instructions.
Phabricator review: http://reviews.llvm.org/D7469
llvm-svn: 228580
|
| |
|
|
| |
llvm-svn: 228579
|
| |
|
|
| |
llvm-svn: 228578
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For the attached test case different types are used in the ICmpInst
and SelectInst that represent the min/max expressions. However, if the
ICmpInst type is smaller a comparison with the sign/zero extended
operands would have yielded the same result. This situation might
arise after the instruction combination pass was applied.
Differential Revision: http://reviews.llvm.org/D7338
llvm-svn: 228572
|
| |
|
|
| |
llvm-svn: 228568
|
| |
|
|
|
|
|
| |
Apparently gcc-4.7.2 is touchy about 'this' appearing in a lambda capture list
along with other captures. I've rewritten my captures to try to avoid the issue.
llvm-svn: 228567
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wrong basic block.
This would happen when the result of an invoke was used by a phi instruction
in the invoke's normal destination block. An instruction to reload the invoke's
value would get inserted before the critical edge was split and a new basic
block (which is the correct insertion point for the reload) was created. This
commit fixes the bug by splitting the critical edge before all the reload
instructions are inserted.
Also, hoist up the code which computes the insertion point to the only place
that need that computation.
rdar://problem/15978721
llvm-svn: 228566
|
| |
|
|
|
|
| |
This fixes PR22060.
llvm-svn: 228565
|
| |
|
|
| |
llvm-svn: 228564
|
| |
|
|
|
|
| |
used.
llvm-svn: 228563
|
| |
|
|
| |
llvm-svn: 228562
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some parts of DeadArgElim were only considering the individual fields
of StructTypes separately, but others (where insertvalue &
extractvalue instructions occur) also looked into ArrayTypes.
This one is an actual bug; the mismatch can lead to an argument being
considered used by a return sub-value that isn't being tracked (and
hence is dead by default). It then gets incorrectly eliminated.
llvm-svn: 228559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a non-extractvalue use of an aggregate return value meant
the entire return was considered live (the algorithm gave up
entirely). This was correct, but conservative. It's better to actually
look at that Use, making the analysis results apply to all sub-values
under consideration.
E.g.
%val = call { i32, i32 } @whatever()
[...]
ret { i32, i32 } %val
The return is using the entire aggregate (sub-values 0 and 1). We can
still simplify @whatever if we can prove that this return is itself
unused.
Also unifies the logic slightly between aggregate and non-aggregate
cases..
llvm-svn: 228558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors a key piece of the Orc APIs: It removes the
*::getSymbolAddress and *::lookupSymbolAddressIn methods, which returned target
addresses (uint64_ts), and replaces them with *::findSymbol and *::findSymbolIn
respectively, which return instances of the new JITSymbol type. Unlike the old
methods, calling findSymbol or findSymbolIn does not cause the symbol to be
immediately materialized when found. Instead, the symbol will be materialized
if/when the getAddress method is called on the returned JITSymbol. This allows
us to query for the existence of symbols without actually materializing them. In
the future I expect more information to be attached to the JITSymbol class, for
example whether the returned symbol is a weak or strong definition. This will
allow us to properly handle weak symbols and multiple definitions.
llvm-svn: 228557
|
| |
|
|
|
|
|
|
|
| |
Make assume (load (call|invoke) != null) set nonNull return attribute
for the call and invoke. Also include tests.
Differential Revision: http://reviews.llvm.org/D7107
llvm-svn: 228556
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7494
llvm-svn: 228555
|
| |
|
|
|
|
| |
of the base class member variable.
llvm-svn: 228554
|
| |
|
|
| |
llvm-svn: 228553
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
add recurrences don't overflow.
This change makes the optimization more restrictive. It still assumes
that an overflowing `add nsw` is undefined behavior; and this change
will need revisiting once we have a consistent semantics for poison
values.
Differential Revision: http://reviews.llvm.org/D7331
llvm-svn: 228552
|
| |
|
|
|
|
| |
patterns. AVX and AVX2 can handle unaligned loads being folded so we can just use 'load'
llvm-svn: 228551
|
| |
|
|
| |
llvm-svn: 228550
|
| |
|
|
| |
llvm-svn: 228546
|
| |
|
|
| |
llvm-svn: 228545
|
| |
|
|
| |
llvm-svn: 228544
|
| |
|
|
|
|
| |
remove an unused parameter.
llvm-svn: 228543
|
| |
|
|
|
|
|
|
|
| |
Dumping a symbol often requires access to data that isn't inside
the symbol hierarchy, but which is only accessible through the
top-level session. This patch is a pure interface change to give
symbols a reference to the session.
llvm-svn: 228542
|
| |
|
|
| |
llvm-svn: 228541
|
| |
|
|
| |
llvm-svn: 228539
|
| |
|
|
| |
llvm-svn: 228537
|
| |
|
|
| |
llvm-svn: 228536
|