| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
specifications in this mode in C++17, since they're part of the function type,
so check and diagnose them like we would if exceptions were enabled.
Better ideas welcome.
llvm-svn: 288220
|
| |
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
https://reviews.llvm.org/D26023
This patch adds support for converting a vector of loads into a single load if
the loads are consecutive (in either direction).
llvm-svn: 288219
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
https://reviews.llvm.org/D25980
This is the 2nd patch in a series of 4 that improve the lowering and combining
for BUILD_VECTOR nodes on PowerPC. This particular patch combines a build vector
of fp-to-int conversions into an fp-to-int conversion of a build vector of fp
values. For example:
Converts (build_vector (fp_to_[su]i $A), (fp_to_[su]i $B), ...)
Into (fp_to_[su]i (build_vector $A, $B, ...))).
Which is a natural match for much cleaner code.
llvm-svn: 288218
|
| |
|
|
| |
llvm-svn: 288217
|
| |
|
|
| |
llvm-svn: 288216
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Previously 0 and -1 was matched via tablegen rules. But this could cause problems where a physical register was being used where a virtual register was expected (seen in optimizeSelect and TwoAddressInstructionPass). Instead follow AArch64 and match in DAGToDAGISel.
Reviewers: eliben, majnemer
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D27171
llvm-svn: 288215
|
| |
|
|
|
|
|
| |
This commit caused some miscompiles that did not show up on any of the bots.
Reverting until we can investigate the cause of those failures.
llvm-svn: 288214
|
| |
|
|
|
|
| |
This preparation to remove SetVector.h dependency on SmallSet.h.
llvm-svn: 288213
|
| |
|
|
|
|
|
|
|
|
|
|
| |
DWARF specifies that "line 0" really means "no appropriate source
location" in the line table. Use this for branch targets and some
other cases that have no specified source location, to prevent
inheriting unfortunate line numbers from physically preceding
instructions (which might be from completely unrelated source).
Differential Revision: http://reviews.llvm.org/D24180
llvm-svn: 288212
|
| |
|
|
|
|
|
|
| |
vcvttpd2dq/vcvttpd2udq implicit zeroing of upper 64-bits of xmm result
Ensure that masked instruction doesn't assume implicit zeroing.
llvm-svn: 288211
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[recommiting patches one-by-one to see which breaks the stage2 LTO bot]
Follow-on patches will add more interesting cases.
The goal of this patch-set is to get the GVN messages printed in
opt-viewer from Dhrystone as was presented in my Dev Meeting talk. This
is the optimization view for the function (the last remark in the
function has a bug which is fixed in this series):
http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L430
Differential Revision: https://reviews.llvm.org/D26488
llvm-svn: 288210
|
| |
|
|
|
|
|
|
| |
of upper 64-bits of xmm result
Ensure that masked instruction doesn't assume implicit zeroing.
llvm-svn: 288209
|
| |
|
|
|
|
| |
builtin with the type of an explicit declaration of the same function.
llvm-svn: 288208
|
| |
|
|
| |
llvm-svn: 288207
|
| |
|
|
|
|
|
|
|
| |
This target hook was added with D19087:
https://reviews.llvm.org/D19087
Differential Revision: https://reviews.llvm.org/D27221
llvm-svn: 288206
|
| |
|
|
| |
llvm-svn: 288205
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27224
llvm-svn: 288204
|
| |
|
|
| |
llvm-svn: 288203
|
| |
|
|
|
|
|
|
| |
llvm-cat and llvm-modextract.
Differential Revision: https://reviews.llvm.org/D27189
llvm-svn: 288202
|
| |
|
|
|
|
|
|
|
|
| |
This program is for testing features that rely on multi-module bitcode files.
It takes a multi-module bitcode file, extracts one of the modules and writes
it to the output file.
Differential Revision: https://reviews.llvm.org/D26778
llvm-svn: 288201
|
| |
|
|
|
|
|
|
|
| |
Michel Dänzer reported that r288051, "[StructurizeCFG] Use range-based
for loops", introduced a bug into rebuildSSA, wherein we were iterating
over an instruction's use list while modifying it, without taking care
to do this correctly.
llvm-svn: 288200
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
-macho option.
In some cases the leading headers of the file name, archive member and
architecture slice name in the output of lvm-objdump is not wanted so the
tool’s output can be directly used by scripts. This matches the -X option
of the Apple otool(1) program.
rdar://28491674
llvm-svn: 288199
|
| |
|
|
| |
llvm-svn: 288198
|
| |
|
|
|
|
|
|
|
| |
Otherwise MSVC and clang-cl will see "extern inline" after merging
redeclarations and emit it in all TUs that include Type.h and Decl.h.
Noticed by inspection, since it's always the first thing to get emitted.
llvm-svn: 288197
|
| |
|
|
|
|
|
|
|
|
| |
NDEBUG
This is consistent with the header (after r288087) and fixes the
test for the configuration:
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ABI_BREAKING_CHECKS=FORCE_OFF
llvm-svn: 288196
|
| |
|
|
|
|
|
|
|
|
| |
This interface allows clients to write multiple modules to a single
bitcode file. Also introduce the llvm-cat utility which can be used
to create a bitcode file containing multiple modules.
Differential Revision: https://reviews.llvm.org/D26179
llvm-svn: 288195
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26972
llvm-svn: 288194
|
| |
|
|
|
|
| |
functions, in order to support constexpr std::char_traits<wchar_t>.
llvm-svn: 288193
|
| |
|
|
| |
llvm-svn: 288192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not in the list of valid inputs for the encoding.
When spilling, copies from exec can be folded directly
into the spill instruction which results in broken
stores.
This only fixes the operand constraints, more codegen
work is required to avoid emitting the invalid
spills.
This sort of breaks the dbg.value test. Because the
register class of the s_load_dwordx2 changes, there
is a copy to SReg_64, and the copy is the operand
of dbg_value. The copy is later dead, and removed
from the dbg_value.
llvm-svn: 288191
|
| |
|
|
| |
llvm-svn: 288190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The code in LiveRangeEdit::eliminateDeadDef() that computes isOrigDef
doesn't handle instructions in which operand 0 is not a def (e.g. KILL)
correctly. Add a check that operand 0 is a def before doing the rest of
the isOrigDef computation.
Reviewers: qcolombet, MatzeB, wmi
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D27174
llvm-svn: 288189
|
| |
|
|
|
|
|
|
|
|
| |
Use vaddr/vdst for the same purposes.
This also fixes a beg in SIInsertWaits for the
operand check. The stored value operand is currently called
data0 in the single offset case, not data.
llvm-svn: 288188
|
| |
|
|
| |
llvm-svn: 288187
|
| |
|
|
|
|
|
|
|
|
| |
in lit tests
The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden).
Differential Revision: https://reviews.llvm.org/D26929
llvm-svn: 288186
|
| |
|
|
|
|
|
|
|
|
|
| |
It isn't generally safe to fold the frame index
directly into the operand since it will possibly
not be an inline immediate after it is expanded.
This surprisingly seems to produce better code, since
the FI doesn't prevent folding other immediate operands.
llvm-svn: 288185
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Change the logic for when to fold immediates to
consider the destination operand rather than the
source of the materializing mov instruction.
No change yet, but this will allow for correctly handling
i16/f16 operands. Since 32-bit moves are used to materialize
constants for these, the same bitvalue will not be in the
register.
llvm-svn: 288184
|
| |
|
|
| |
llvm-svn: 288183
|
| |
|
|
|
|
|
| |
This patch is to avoid an implicit conversion from const char * to
StringRefZ, to make it apparent where we are using StringRefZ.
llvm-svn: 288182
|
| |
|
|
|
|
|
|
| |
It seems a debug build of lldb-server will not complete without these, as the
linker is not able to strip out code that aggressively. Add those back until I
can figure out how to break the dependency chains.
llvm-svn: 288181
|
| |
|
|
| |
llvm-svn: 288180
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r288046.
Trying to see if the revert fixes a compiler crash during a stage2 LTO
build with a GVN backtrace.
llvm-svn: 288179
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r288047.
Trying to see if the revert fixes a compiler crash during a stage2 LTO
build with a GVN backtrace.
llvm-svn: 288178
|
| |
|
|
|
|
|
|
|
|
|
| |
load-elimination"
This reverts commit r288090.
Trying to see if the revert fixes a compiler crash during a stage2 LTO
build with a GVN backtrace.
llvm-svn: 288177
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In AArch64InstrInfo::foldMemoryOperandImpl, catch more cases where the
COPY being spilled is copying from WZR/XZR, but the source register is
not in the COPY destination register's regclass.
For example, when spilling:
%vreg0 = COPY %XZR ; %vreg0:GPR64common
without this change, the code in TargetInstrInfo::foldMemoryOperand()
and canFoldCopy() that normally handles cases like this would fail to
optimize since %XZR is not in GPR64common. So the spill code generated
would be:
%vreg0 = COPY %XZR
STR %vreg
instead of the new code generated:
STR %XZR
Reviewers: qcolombet, MatzeB
Subscribers: mcrosier, aemerson, t.p.northover, llvm-commits, rengolin
Differential Revision: https://reviews.llvm.org/D26976
llvm-svn: 288176
|
| |
|
|
|
|
|
|
| |
other minor fixes (NFC).
This preparation to remove SetVector.h dependency on SmallSet.h.
llvm-svn: 288175
|
| |
|
|
|
|
|
|
| |
other minor fixes (NFC).
This preparation to remove SetVector.h dependency on SmallSet.h.
llvm-svn: 288174
|
| |
|
|
|
|
| |
This reverts commit r288162. Buildbot clang-bpf-build fails running tests.
llvm-svn: 288173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringRefZ is a class to represent a null-terminated string. String
length is computed lazily, so it's more efficient than StringRef to
represent strings in string table.
The motivation of defining this new class is to merge functions
that only differ in string types; we have many constructors that takes
`const char *` or `StringRef`. With StringRefZ, we can merge them.
Differential Revision: https://reviews.llvm.org/D27037
llvm-svn: 288172
|
| |
|
|
|
|
|
|
|
|
| |
While reading the LTO docs I fixed few small typos and whitespace issues.
Patch by: Jonas Devlieghere <jonas@devlieghere.com>
Differential Revision: https://reviews.llvm.org/D27196
llvm-svn: 288171
|