| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just an initial checkin of an implementation of the Relooper algorithm, in preparation for WebAssembly codegen to utilize. It doesn't do anything yet by itself.
The Relooper algorithm takes an arbitrary control flow graph and generates structured control flow from that, utilizing a helper variable when necessary to handle irreducibility. The WebAssembly backend will be able to use this in order to generate an AST for its binary format.
Author: azakai
Reviewers: jfb, sunfish
Subscribers: jevinskie, arsenm, jroelofs, llvm-commits
Differential revision: http://reviews.llvm.org/D11691
llvm-svn: 245142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
|
| |
|
|
|
|
|
|
|
| |
This seems to only work some of the time. In some situations,
this seems to use a nonsensical type and isn't actually aware of the
memory being accessed. e.g. if branch condition is an icmp of a pointer,
it checks the addressing mode of i1.
llvm-svn: 245137
|
| |
|
|
|
|
|
| |
The comments at the bottom would all report 0 if
amdhsa was used.
llvm-svn: 245135
|
| |
|
|
|
|
|
| |
This is simple but won't work if/when this pass
is moved to be post-SSA.
llvm-svn: 245134
|
| |
|
|
|
|
|
|
|
| |
Does not mark SlotIndexes as reserved, although I think
that might be OK.
LiveVariables still need to be handled.
llvm-svn: 245133
|
| |
|
|
|
|
|
| |
These shouldn't ever be null. The number of successors
was already asserted to be 2.
llvm-svn: 245132
|
| |
|
|
|
|
|
|
|
|
|
| |
True branch instructions do behave as expected with liveness.
Avoid the phrasing "branch decision is based on a value in an SGPR"
because this could be misleading. A VALU compare instruction's
result is still based on an SGPR, even though that condition
may be divergent.
llvm-svn: 245131
|
| |
|
|
|
|
| |
created a value with the wrong type. Fixes PR24458!
llvm-svn: 245119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
http://reviews.llvm.org/D11212 made Scalar Evolution able to propagate NSW and NUW flags from instructions to SCEVs for add instructions. This patch expands that to sub, mul and shl instructions.
This change makes LSR able to generate pointer induction variables for loops like these, where the index is 32 bit and the pointer is 64 bit:
for (int i = 0; i < numIterations; ++i)
sum += ptr[i - offset];
for (int i = 0; i < numIterations; ++i)
sum += ptr[i * stride];
for (int i = 0; i < numIterations; ++i)
sum += ptr[3 * (i << 7)];
Reviewers: atrick, sanjoy
Subscribers: sanjoy, majnemer, hfinkel, llvm-commits, meheff, jingyue, eliben
Differential Revision: http://reviews.llvm.org/D11860
llvm-svn: 245118
|
| |
|
|
|
|
|
|
|
|
| |
Although targeting CoreCLR is similar to targeting MSVC, there are
certain important differences that the backend must be aware of
(e.g. differences in stack probes, EH, and library calls).
Differential Revision: http://reviews.llvm.org/D11012
llvm-svn: 245115
|
| |
|
|
|
|
|
|
|
| |
We canonicalize V64 vectors to V128 through insert_subvector: the other
FMLA/FMLS/FMUL/FMULX patterns match that already, but this one doesn't,
so we'd fail to match fmls and generate fneg+fmla instead.
The vector equivalents are already tested and functional.
llvm-svn: 245107
|
| |
|
|
|
|
|
| |
MSan instrumentation for return values of musttail calls is not
allowed by the IR constraints, and not needed at the same time.
llvm-svn: 245106
|
| |
|
|
| |
llvm-svn: 245103
|
| |
|
|
|
|
| |
values.
llvm-svn: 245098
|
| |
|
|
| |
llvm-svn: 245097
|
| |
|
|
|
|
|
|
| |
The compiler was failing to spill for some shaders.
Patch By: Axel Davy
llvm-svn: 245087
|
| |
|
|
|
|
| |
This reverts commit r245081, as it breaks many builds.
llvm-svn: 245086
|
| |
|
|
| |
llvm-svn: 245085
|
| |
|
|
| |
llvm-svn: 245082
|
| |
|
|
|
|
|
|
|
|
| |
This patch makes the Darwin ARM backend take advantage of TargetParser. It
also teaches TargetParser about ARMV7K for the first time. This makes target
triple parsing more consistent across llvm.
Differential Revision: http://reviews.llvm.org/D11996
llvm-svn: 245081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the x86 implementation of allowsMisalignedMemoryAccess() to correctly
return the 'Fast' output parameter for 32-byte accesses. To test that, an existing load
merging optimization is changed to use the TLI hook. This exposes a shortcoming in the
current logic and results in the regression test update. Changing other direct users of
the isUnalignedMem32Slow() x86 CPU attribute would be a follow-on patch.
Without the fix in allowsMisalignedMemoryAccesses(), we will infinite loop when targeting
SandyBridge because LowerINSERT_SUBVECTOR() creates 32-byte loads from two 16-byte loads
while PerformLOADCombine() splits them back into 16-byte loads.
Differential Revision: http://reviews.llvm.org/D10662
llvm-svn: 245075
|
| |
|
|
| |
llvm-svn: 245072
|
| |
|
|
|
|
|
|
| |
This patch will be redone in a different way. See
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150810/292978.html
for more details.
llvm-svn: 245071
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Similar to the change we applied to ASan. The same test case works.
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11961
llvm-svn: 245067
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r245047.
It was failing on the darwin bots. The problem was that when running
./bin/llc -march=msp430
llc gets to
if (TheTriple.getTriple().empty())
TheTriple.setTriple(sys::getDefaultTargetTriple());
Which means that we go with an arch of msp430 but a triple of
x86_64-apple-darwin14.4.0 which fails badly.
That code has to be updated to select a triple based on the value of
march, but that is not a trivial fix.
llvm-svn: 245062
|
| |
|
|
| |
llvm-svn: 245058
|
| |
|
|
|
|
|
|
|
|
|
| |
Other than some places that were handling unknown as ELF, this should
have no change. The test updates are because we were detecting
arm-coff or x86_64-win64-coff as ELF targets before.
It is not clear if the enum should live on the Triple. At least now it lives
in a single location and should be easier to move somewhere else.
llvm-svn: 245047
|
| |
|
|
|
|
|
| |
This allows other areas of the compiler to use BDCE's bit-tracking.
NFCI.
llvm-svn: 245039
|
| |
|
|
|
|
|
|
| |
Spotted by Ahmed - in r244594 I inadvertently marked f16 min/max as legal.
I've reverted it here, and marked min/max on scalar f16's as promote. I've also added a testcase. The test just checks that the compiler doesn't fall over - it doesn't create fmin nodes for f16 yet.
llvm-svn: 245035
|
| |
|
|
| |
llvm-svn: 245032
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code-section alignment should be at least as high as the minimum
stub alignment. If the section alignment is lower it can cause
padding to be emitted resulting in alignment errors if the section
is mapped to a higher alignment on the target.
E.g. If a text section with a 4-byte alignment gets 4-bytes of
padding to guarantee 8-byte alignment for stubs but is re-mapped to
an 8-byte alignment on the target, the 4-bytes of padding will push
the stubs to 4-byte alignment causing a crash.
No test case: There is currently no way to control host section
alignment in llvm-rtdyld. This could be made testable by adding
a custom memory manager. I'll look at that in a follow-up patch.
llvm-svn: 245031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the basic functionality to support "token types".
The motivation stems from the need to perform operations on a Value
whose provenance cannot be obscured.
There are several applications for such a type but my immediate
motivation stems from WinEH. Our personality routine enforces a
single-entry - single-exit regime for cleanups. After several rounds of
optimizations, we may be left with a terminator whose "cleanup-entry
block" is not entirely clear because control flow has merged two
cleanups together. We have experimented with using labels as operands
inside of instructions which are not terminators to indicate where we
came from but found that LLVM does not expect such exotic uses of
BasicBlocks.
Instead, we can use this new type to clearly associate the "entry point"
and "exit point" of our cleanup. This is done by having the cleanuppad
yield a Token and consuming it at the cleanupret.
The token type makes it impossible to obscure or otherwise hide the
Value, making it trivial to track the relationship between the two
points.
What is the burden to the optimizer? Well, it turns out we have already
paid down this cost by accepting that there are certain calls that we
are not permitted to duplicate, optimizations have to watch out for
such instructions anyway. There are additional places in the optimizer
that we will probably have to update but early examination has given me
the impression that this will not be heroic.
Differential Revision: http://reviews.llvm.org/D11861
llvm-svn: 245029
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables dead stroe elimination across basicblocks.
Example:
define void @test_02(i32 %N) {
%1 = alloca i32
store i32 %N, i32* %1
store i32 10, i32* @x
%2 = load i32, i32* %1
%3 = icmp ne i32 %2, 0
br i1 %3, label %4, label %5
; <label>:4
store i32 5, i32* @x
br label %7
; <label>:5
%6 = load i32, i32* @x
store i32 %6, i32* @y
br label %7
; <label>:7
store i32 15, i32* @x
ret void
}
In the above example dead store "store i32 5, i32* @x" is now eliminated.
Differential Revision: http://reviews.llvm.org/D11143
llvm-svn: 245025
|
| |
|
|
|
|
| |
normalize its formatting before I make more substantial changes.
llvm-svn: 245024
|
| |
|
|
|
|
| |
their headers.
llvm-svn: 245023
|
| |
|
|
|
|
| |
Identified by the clang static analyzer. No functional change intended.
llvm-svn: 245022
|
| |
|
|
|
|
|
|
|
| |
its creation function.
This required shifting a bunch of method definitions to be out-of-line
so that we could leave most of the implementation guts in the .cpp file.
llvm-svn: 245021
|
| |
|
|
|
|
| |
its creation function. Update the relevant includes accordingly.
llvm-svn: 245019
|
| |
|
|
|
|
| |
before making substantial changes.
llvm-svn: 245017
|
| |
|
|
| |
llvm-svn: 245015
|
| |
|
|
|
|
| |
formatting.
llvm-svn: 245014
|
| |
|
|
|
|
| |
creation function into that header.
llvm-svn: 245013
|
| |
|
|
|
|
|
|
|
| |
creation function there.
Same basic refactoring as the other alias analyses. Nothing special
required this time around.
llvm-svn: 245012
|
| |
|
|
|
|
|
| |
satisfy libc++'s std::forward_list which requires the value type to be
complete.
llvm-svn: 245011
|
| |
|
|
|
|
| |
substantial changes to normalize any formatting.
llvm-svn: 245010
|
| |
|
|
|
|
|
|
|
|
| |
I've used forward declarations and reorderd the source code some to make
this reasonably clean and keep as much of the code as possible in the
source file, including all the stratified set details. Just the basic AA
interface and the create function are in the header file, and the header
file is now included into the relevant locations.
llvm-svn: 245009
|
| |
|
|
|
|
|
|
|
| |
.cpp file to make the header much less noisy.
Also makes it easy to use a static helper rather than a public method
for printing lines of stats.
llvm-svn: 245006
|
| |
|
|
|
|
| |
for subsequent changes.
llvm-svn: 245005
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pattern.
Also hoist the creation routine out of the generic header and into the
pass header now that we have one.
I've worked to not make any changes, even formatting ones here. I'll
clean up the formatting and other things in a follow-up patch now that
the code is in the right place.
llvm-svn: 245004
|