| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 202134
|
| |
|
|
| |
llvm-svn: 202130
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the break statement, not just think it to yourself....
No idea how this worked at all, much less survived most bots, my
bootstrap, and some bot bootstraps!
The Polly one didn't survive, and this was filed as PR18959. I don't
have a reduced test case and honestly I'm not seeing the need. What we
probably need here are better asserts / debug-build behavior in
SmallPtrSet so that this madness doesn't make it so far.
llvm-svn: 202129
|
| |
|
|
| |
llvm-svn: 202119
|
| |
|
|
| |
llvm-svn: 202107
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
sorting it. This helps uncover latent reliance on the original ordering
which aren't guaranteed to be preserved by std::sort (but often are),
and which are based on the use-def chain orderings which also aren't
(technically) guaranteed.
Only available in C++11 debug builds, and behind a flag to prevent noise
at the moment, but this is generally useful so figured I'd put it in the
tree rather than keeping it out-of-tree.
llvm-svn: 202106
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the destination operand or source operand of a memmove.
It so happens that it was impossible for SROA to try to rewrite
self-memmove where the operands are *identical*, because either such
a think is volatile (and we don't rewrite) or it is non-volatile, and we
don't even register it as a use of the alloca.
However, making the 'IsDest' test *rely* on this subtle fact is... Very
confusing for the reader. We should use the direct and readily available
test of the Use* which gives us concrete information about which operand
is being rewritten.
No functionality changed, I hope! ;]
llvm-svn: 202103
|
| |
|
|
| |
llvm-svn: 202096
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ordering.
The fundamental problem that we're hitting here is that the use-def
chain ordering is *itself* not a stable thing to be relying on in the
rewriting for SROA. Further, we use a non-stable sort over the slices to
arrange them based on the section of the alloca they're operating on.
With a debugging STL implementation (or different implementations in
stage2 and stage3) this can cause stage2 != stage3.
The specific aspect of this problem fixed in this commit deals with the
rewriting and load-speculation around PHIs and Selects. This, like many
other aspects of the use-rewriting in SROA, is really part of the
"strong SSA-formation" that is doen by SROA where it works very hard to
canonicalize loads and stores in *just* the right way to satisfy the
needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the
same alloca, we test that loads downstream of the select are
speculatable around it twice. If only one of the operands to the select
needs to be rewritten, then if we get lucky we rewrite that one first
and the select is immediately speculatable. This can cause the order of
operand visitation, and thus the order of slices to be rewritten, to
change an alloca from promotable to non-promotable and vice versa.
The fix is to defer all of the speculation until *after* the rewrite
phase is done. Once we've rewritten everything, we can accurately test
for whether speculation will work (once, instead of twice!) and the
order ceases to matter.
This also happens to simplify the other subtlety of speculation -- we
need to *not* speculate anything unless the result of speculating will
make the alloca fully promotable by mem2reg. I had a previous attempt at
simplifying this, but it was still pretty horrible.
There is actually already a *really* nice test case for this in
basictest.ll, but on multiple STL implementations and inputs, we just
got "lucky". Fortunately, the test case is very small and we can
essentially build it in exactly the opposite way to get reasonable
coverage in both directions even from normal STL implementations.
llvm-svn: 202092
|
| |
|
|
|
|
| |
units under fission.
llvm-svn: 202091
|
| |
|
|
|
|
| |
No functionality change. Just reduces the noise of an upcoming patch.
llvm-svn: 202087
|
| |
|
|
| |
llvm-svn: 202084
|
| |
|
|
| |
llvm-svn: 202080
|
| |
|
|
|
|
|
| |
Does not yet include larger part required
to match v_mad_i64_i32 / v_mad_u64_u32.
llvm-svn: 202077
|
| |
|
|
|
|
|
| |
The check is clearer as southern islands or later,
rather than checking for later than northern islands.
llvm-svn: 202076
|
| |
|
|
| |
llvm-svn: 202075
|
| |
|
|
| |
llvm-svn: 202074
|
| |
|
|
| |
llvm-svn: 202073
|
| |
|
|
|
|
|
|
|
| |
Vectorize sequential stores of a broadcasted value.
5% on eon.
radar://16124699
llvm-svn: 202067
|
| |
|
|
|
|
|
|
|
|
| |
The patch defines new or refines existing generic scheduling classes to match
the behavior of the SSE instructions.
It also maps those scheduling classes on the related SSE instructions.
<rdar://problem/15607571>
llvm-svn: 202065
|
| |
|
|
| |
llvm-svn: 202057
|
| |
|
|
|
|
|
|
|
| |
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
llvm-svn: 202052
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
During the LTO phase LICM will move loop invariant global variables out of loops
(informed by GlobalModRef). This makes more loops countable presenting
opportunity for the loop vectorizer.
Adding the loop vectorizer improves some TSVC benchmarks and twolf/ref dataset
(5%) on x86-64.
radar://15970632
llvm-svn: 202051
|
| |
|
|
|
|
| |
This will make it easier to switch the default to being binary files.
llvm-svn: 202042
|
| |
|
|
|
|
| |
internal flags that allowed to override it. The tests pass, but still this change might break asan on some platform not covered by tests. If you see this, please submit a fix with a test.
llvm-svn: 202033
|
| |
|
|
| |
llvm-svn: 202024
|
| |
|
|
| |
llvm-svn: 202015
|
| |
|
|
|
|
|
| |
The only extra bit of functionality that had to be exposed for this be be
implemented in Path.cpp is opening a file in rw mode.
llvm-svn: 202005
|
| |
|
|
| |
llvm-svn: 202001
|
| |
|
|
|
|
|
|
| |
The .error directive is similar to .err in that it will halt assembly if it is
evaluated for assembly. However, it permits a user supplied message to be
rendered.
llvm-svn: 201999
|
| |
|
|
|
|
|
| |
The .ifeqs directive assembles the following code if the quoted string
parameters are equal. The strings must be quoted using double quotes.
llvm-svn: 201998
|
| |
|
|
| |
llvm-svn: 201994
|
| |
|
|
| |
llvm-svn: 201989
|
| |
|
|
|
|
|
|
| |
.align is handled specially on certain targets. .align without any parameters
on ARM indicates a default alignment (4). Handle the special case in the target
parser, but fall back to the generic parser for the normal version.
llvm-svn: 201988
|
| |
|
|
|
|
|
| |
The .ifne directive assembles the following section of code if the argument
expression is non-zero. Effectively, it is equivalent to if.
llvm-svn: 201986
|
| |
|
|
|
|
|
|
| |
If the strings are not quoted, the first string stops at the first comma, and
the second string stops at the end of the line. Strings which contain
whitespace should be quoted. Unquoted space is to be discarded.
llvm-svn: 201985
|
| |
|
|
|
|
|
| |
The .err directive produces an error whenever it is assembled. This can be
useful for preventing assembly when an unexpected condition occurs.
llvm-svn: 201984
|
| |
|
|
| |
llvm-svn: 201983
|
| |
|
|
| |
llvm-svn: 201980
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch they would take an boolean argument to say if the path
already existed. This was redundant with the returned error_code which is able
to represent that. This allowed for callers to incorrectly check only the
existed flag instead of first checking the error code.
Instead, pass in a boolean flag to say if the previous (non-)existence should be
an error or not.
Callers of the of the old simple versions are not affected. They still ignore
the previous (non-)existence as they did before.
llvm-svn: 201979
|
| |
|
|
| |
llvm-svn: 201975
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 201974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LLVMSupport library implementation consolidates all dependencies on
system libraries. Move the logic gathering system libraries out of
'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'.
Use the target_link_libraries() command there to tell CMake about the
link dependencies of the LLVMSupport implementation. CMake will
automatically propagate this to all targets that link LLVMSupport
directly or indirectly.
We still need to build knowledge of system library dependencies into
'llvm-config'. Store the list of libraries needed in a property on
LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it
from there.
Drop all calls to 'link_system_libs' and 'get_system_libs' from our
CMake code. Replace their implementations with a warning that explains
the calls are no longer necessary. Also drop from 'LLVMConfig.cmake'
the HAVE_* and related variables that were published there only to allow
'get_system_libs' to run outside our build process.
Contributed by Brad King.
llvm-svn: 201969
|
| |
|
|
|
|
|
|
| |
This adds support for the .short and its alias .hword for adding literal values
into the object file. This is similar to the .word directive, however, rather
than inserting a value of 4 bytes, adds a 2-byte value.
llvm-svn: 201968
|
| |
|
|
| |
llvm-svn: 201944
|
| |
|
|
|
|
|
|
| |
Offsets past the range of single-slash encoding are encoded as base64,
padded to 6 characters, and prefixed with two slashes. This encoding is
undocumented but used by MSVC.
llvm-svn: 201940
|
| |
|
|
| |
llvm-svn: 201939
|
| |
|
|
|
|
|
|
|
|
| |
This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.
Besides, this commit also adds some unit tests for the LEB128
functions.
llvm-svn: 201937
|
| |
|
|
| |
llvm-svn: 201930
|
| |
|
|
|
|
|
|
|
| |
The API expects an ISD opcode, not an IR opcode.
Fixes a regression for R600.
Related to <rdar://problem/15519855>.
llvm-svn: 201923
|