| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Extract element instructions that will be removed when vectorzing lower the
cost.
Patch by Arch D. Robison!
llvm-svn: 205020
|
|
|
|
|
|
| |
Patch by Arch D. Robison!
llvm-svn: 205019
|
|
|
|
|
|
| |
Patch by Arch D. Robison!
llvm-svn: 205018
|
|
|
|
|
|
|
|
|
| |
This reverts commit r204912, and follow-up commit r204948.
This introduced a performance regression, and the fix is not completely
clear yet.
llvm-svn: 205010
|
|
|
|
|
|
|
|
|
| |
This reverts commit r203553, and follow-up commits r203558 and r203574.
I will follow this up on the mailinglist to do it in a way that won't
cause subtle PRE bugs.
llvm-svn: 205009
|
|
|
|
| |
llvm-svn: 204981
|
|
|
|
|
|
|
|
|
| |
Fixes a miscompile introduced in r204912. It would miscompile code like
(unsigned)(a + -49) <= 5U. The transform would turn this into
(unsigned)a < 55U, which would return true for values in [0, 49], when
it should not.
llvm-svn: 204948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds back r204781.
Original message:
Aliases are just another name for a position in a file. As such, the
regular symbol resolutions are not applied. For example, given
define void @my_func() {
ret void
}
@my_alias = alias weak void ()* @my_func
@my_alias2 = alias void ()* @my_alias
We produce without this patch:
.weak my_alias
my_alias = my_func
.globl my_alias2
my_alias2 = my_alias
That is, in the resulting ELF file my_alias, my_func and my_alias are
just 3 names pointing to offset 0 of .text. That is *not* the
semantics of IR linking. For example, linking in a
@my_alias = alias void ()* @other_func
would require the strong my_alias to override the weak one and
my_alias2 would end up pointing to other_func.
There is no way to represent that with aliases being just another
name, so the best solution seems to be to just disallow it, converting
a miscompile into an error.
llvm-svn: 204934
|
|
|
|
|
|
|
|
|
|
| |
Transform:
icmp X+Cst2, Cst
into:
icmp X, Cst-Cst2
when Cst-Cst2 does not overflow, and the add has nsw.
llvm-svn: 204912
|
|
|
|
|
|
| |
by Björn Steinbrink!
llvm-svn: 204876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Tested with a unit test because we don't appear to have any transforms
that use this other than ASan, I think.
Fixes PR17935.
Reviewers: nicholas
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3194
llvm-svn: 204866
|
|
|
|
|
|
|
|
|
| |
This reverts commit r204781.
I will follow up to with msan folks to see what is what they
were trying to do with aliases to weak aliases.
llvm-svn: 204784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aliases are just another name for a position in a file. As such, the
regular symbol resolutions are not applied. For example, given
define void @my_func() {
ret void
}
@my_alias = alias weak void ()* @my_func
@my_alias2 = alias void ()* @my_alias
We produce without this patch:
.weak my_alias
my_alias = my_func
.globl my_alias2
my_alias2 = my_alias
That is, in the resulting ELF file my_alias, my_func and my_alias are
just 3 names pointing to offset 0 of .text. That is *not* the
semantics of IR linking. For example, linking in a
@my_alias = alias void ()* @other_func
would require the strong my_alias to override the weak one and
my_alias2 would end up pointing to other_func.
There is no way to represent that with aliases being just another
name, so the best solution seems to be to just disallow it, converting
a miscompile into an error.
llvm-svn: 204781
|
|
|
|
|
|
| |
collectConstantCandidates method.
llvm-svn: 204758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously the code didn't check if the before and after types for the
store were pointers to different address spaces. This resulted in
instcombine using a bitcast to convert between pointers to different
address spaces, causing an assertion due to the invalid cast.
It is not be appropriate to use addrspacecast this case because it is
not guaranteed to be a no-op cast. Instead bail out and do not do the
transformation.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3117
llvm-svn: 204733
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 204732
|
|
|
|
|
|
|
|
|
| |
Some bits of select result may be initialized even if select condition
is not.
https://code.google.com/p/memory-sanitizer/issues/detail?id=50
llvm-svn: 204716
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extracts coming from phis were being hoisted, while all others were
sunk to their uses. This was inconsistent and didn't seem to serve a
purpose. Changing all extracts to be sunk to uses is a prerequisite
for adding block frequency to the SLP vectorizer's cost model.
I benchmarked the change in isolation (without block frequency). I
only saw noise on x86 and some potentially significant improvements on
ARM. No major regressions is good enough for me.
llvm-svn: 204699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.
include/llvm/CodeGen/MachineSSAUpdater.h | 1
include/llvm/IR/DebugInfo.h | 3
lib/CodeGen/MachineSSAUpdater.cpp | 10 --
lib/CodeGen/PostRASchedulerList.cpp | 1
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 10 --
lib/IR/DebugInfo.cpp | 12 --
lib/MC/MCAsmStreamer.cpp | 2
lib/Support/YAMLParser.cpp | 39 ---------
lib/TableGen/TGParser.cpp | 16 ---
lib/TableGen/TGParser.h | 1
lib/Target/AArch64/AArch64TargetTransformInfo.cpp | 9 --
lib/Target/ARM/ARMCodeEmitter.cpp | 12 --
lib/Target/ARM/ARMFastISel.cpp | 84 --------------------
lib/Target/Mips/MipsCodeEmitter.cpp | 11 --
lib/Target/Mips/MipsConstantIslandPass.cpp | 12 --
lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp | 21 -----
lib/Target/NVPTX/NVPTXISelDAGToDAG.h | 2
lib/Target/PowerPC/PPCFastISel.cpp | 1
lib/Transforms/Instrumentation/AddressSanitizer.cpp | 2
lib/Transforms/Instrumentation/BoundsChecking.cpp | 2
lib/Transforms/Instrumentation/MemorySanitizer.cpp | 1
lib/Transforms/Scalar/LoopIdiomRecognize.cpp | 8 -
lib/Transforms/Scalar/SCCP.cpp | 1
utils/TableGen/CodeEmitterGen.cpp | 2
24 files changed, 2 insertions(+), 261 deletions(-)
llvm-svn: 204560
|
|
|
|
|
|
|
|
| |
benchmarks.
<rdar://problem/16368461>
llvm-svn: 204558
|
|
|
|
|
|
|
| |
The cleanup code that removes dead cast instructions only removed them from the
basic block, but didn't delete them. This fix erases them now too.
llvm-svn: 204538
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A PHI node usually has only one value/basic block pair per incoming basic block.
In the case of a switch statement it is possible that a following PHI node may
have more than one such pair per incoming basic block. E.g.:
%0 = phi i64 [ 123456, %case2 ], [ 654321, %Entry ], [ 654321, %Entry ]
This is valid and the verfier doesn't complain, because both values are the
same.
Constant hoisting materializes the constant for each operand separately and the
value is still the same, but the variable names have changed. As a result the
verfier can't recognize anymore that they are the same value and complains.
This fix adds special update code for PHI node in constant hoisting to prevent
this corner case.
This fixes <rdar://problem/16394449>
llvm-svn: 204537
|
|
|
|
| |
llvm-svn: 204526
|
|
|
|
|
|
|
| |
CodeGen treats allocas outside the entry block as dynamically sized
stack objects.
llvm-svn: 204473
|
|
|
|
|
|
|
|
|
| |
Extend the target hook to take also the operand index into account when
calculating the cost of the constant materialization.
Related to <rdar://problem/16381500>
llvm-svn: 204435
|
|
|
|
|
|
| |
Related to <rdar://problem/16381500>
llvm-svn: 204434
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
Originally the algorithm would search for expensive constants and track their
users, which could be instructions and constant expressions. This change only
tracks the constants for instructions, but constant expressions are indirectly
covered too. If an operand is an constant expression, then we look through the
expression to find anny expensive constants.
The algorithm keep now track of the instruction and the operand index where the
constant is used. This allows more precise hoisting of constant materialization
code for PHI instructions, because we only hoist to the basic block of the
incoming operand. Before we had to find the idom of all PHI operands and hoist
the materialization code there.
This also makes updating of instructions easier. Before we had to keep track of
the original constant, find it in the instructions, and then replace it. Now we
can just simply update the operand.
Related to <rdar://problem/16381500>
llvm-svn: 204433
|
|
|
|
| |
llvm-svn: 204432
|
|
|
|
|
|
|
|
|
|
|
| |
keep track of constant candidates.
This simplifies working with the constant candidates and removes the tight
coupling between the map and the vector.
Related to <rdar://problem/16381500>
llvm-svn: 204431
|
|
|
|
|
|
| |
I will break this up into smaller pieces for review and recommit.
llvm-svn: 204393
|
|
|
|
|
|
|
|
|
| |
This commit extends the coverage of the constant hoisting pass, adds additonal
debug output and updates the function names according to the style guide.
Related to <rdar://problem/16381500>
llvm-svn: 204389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option caused LowerInvoke to generate code using SJLJ-based
exception handling, but there is no code left that interprets the
jmp_buf stack that the resulting code maintained (llvm.sjljeh.jblist).
This option has been obsolete for a while, and replaced by
SjLjEHPrepare.
This leaves the default behaviour of LowerInvoke, which is to convert
invokes to calls.
Differential Revision: http://llvm-reviews.chandlerc.com/D3136
llvm-svn: 204388
|
|
|
|
|
|
| |
Fixes https://code.google.com/p/address-sanitizer/issues/detail?id=279.
llvm-svn: 204331
|
|
|
|
| |
llvm-svn: 204230
|
|
|
|
|
|
|
|
|
|
| |
The use_iterator redesign in r203364 introduced an increment past the
end of a range in -objc-arc-contract. Added an explicit check for the
end of the range.
<rdar://problem/16333235>
llvm-svn: 204195
|
|
|
|
|
|
| |
for this kind of walk.
llvm-svn: 204188
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
noise.
Original commit log:
Replace some dead code with an assert. When I first ported this pass
from a loop pass to a function pass I did so in the naive, recursive
way. It doesn't actually work, we need a worklist instead. When
I switched to the worklist I didn't delete the naive recursion. That
recursion was also buggy because it was dead and never really exercised.
llvm-svn: 204187
|
|
|
|
|
|
|
|
|
|
| |
pass from a loop pass to a function pass I did so in the naive,
recursive way. It doesn't actually work, we need a worklist instead.
When I switched to the worklist I didn't delete the naive recursion.
That recursion was also buggy because it was dead and never really
exercised.
llvm-svn: 204184
|
|
|
|
|
|
|
|
| |
LLVM part of MSan implementation of advanced origin tracking,
when we record not only creation point, but all locations where
an uninitialized value was stored to memory, too.
llvm-svn: 204151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The compiler does not always generate linkage names. If a function
has been inlined and its body elided, its linkage name may not be
generated.
When the binary executes, the profiler will use its unmangled name
when attributing samples. This results in unmangled names in the
input profile.
We are currently failing hard when this happens. However, in this case
all that happens is that we fail to attribute samples to the inlined
function. While this means fewer optimization opportunities, it should
not cause a compilation failure.
This patch accepts all valid function names, regardless of whether
they were mangled or not.
Reviewers: chandlerc
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3087
llvm-svn: 204142
|
|
|
|
|
|
|
| |
Not only is it slower than the alternative, but also subtly broken.
This commit does not change the default behavior.
llvm-svn: 204131
|
|
|
|
|
|
| |
Also changes the iterators to return actual DI type over MDNode.
llvm-svn: 204130
|
|
|
|
| |
llvm-svn: 204125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When GlobalOpt has determined that a GlobalVariable only ever has two values,
it would convert the GlobalVariable to a boolean, and introduce SelectInsts
at every load, to choose between the two possible values. These SelectInsts
introduce overhead and other unpleasantness.
This patch makes GlobalOpt just add range metadata to loads from such
GlobalVariables instead. This enables the same main optimization (as seen in
test/Transforms/GlobalOpt/integer-bool.ll), without introducing selects.
The main downside is that it doesn't get the memory savings of shrinking such
GlobalVariables, but this is expected to be negligible.
llvm-svn: 204076
|
|
|
|
|
|
|
|
|
| |
The "noduplicate" attribute of call instructions is sometimes queried directly
and sometimes through the cannotDuplicate() predicate. This patch streamlines
all queries to use the cannotDuplicate() predicate. It also adds this predicate
to InvokeInst, to mirror what CallInst has.
llvm-svn: 204049
|
|
|
|
|
|
|
| |
While technically correct, we generally disallow any instance of named
Twines due to their subtlety.
llvm-svn: 204016
|
|
|
|
| |
llvm-svn: 204013
|
|
|
|
|
|
|
| |
Also convert a horrible hash function to use our hashing infrastructure.
No functionality change.
llvm-svn: 204008
|
|
|
|
| |
llvm-svn: 203996
|
|
|
|
|
|
|
| |
Twine was too short.
FIXME: DiagnosticInfoSampleProfile should not hold Twine&.
llvm-svn: 203990
|