| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 288170
|
| |
|
|
|
| |
FIXME: Implement checks without weak for them.
llvm-svn: 288168
|
| |
|
|
| |
llvm-svn: 288167
|
| |
|
|
|
|
| |
The flag was removed by 288154
llvm-svn: 288161
|
| |
|
|
|
|
| |
The flag was introduced because the optimization controlled by the flag initially caused regressions. All the regressions were fixed some time ago and the flag has been false for quite a while.
llvm-svn: 288154
|
| |
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
https://reviews.llvm.org/D25912
This is the first patch in a series of 4 that improve the lowering and combining
for BUILD_VECTOR nodes on PowerPC.
llvm-svn: 288152
|
| |
|
|
|
|
| |
instruction.
llvm-svn: 288148
|
| |
|
|
|
|
| |
understandable. NFCI.
llvm-svn: 288147
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27110
llvm-svn: 288142
|
| |
|
|
|
|
|
|
|
| |
Enable scalar hoisting at -Oz as it is safe to hoist scalars to a place
where they are partially needed.
Differential Revision: https://reviews.llvm.org/D27111
llvm-svn: 288141
|
| |
|
|
|
|
| |
We can only handle 128-bit vectors until we support target shuffle inputs of different size to the output.
llvm-svn: 288140
|
| |
|
|
| |
llvm-svn: 288138
|
| |
|
|
| |
llvm-svn: 288136
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
logic.
Yup, the invalidation logic has an invalid iterator bug. Can't make this
stuff up.
We can recursively insert things into the map so we can't cache the
iterator into that map across those recursive calls. We did this
differently in two places. I have an end-to-end test that triggers at
least one of them. I'm going to work on a nice minimal test case that
triggers these, but I didn't want to leave the bug in the tree while
I tried to trigger it.
Also, the dense map iterator checking stuff we have now is awesome. =D
llvm-svn: 288135
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This makes the default constructor implicitly constexpr and noexcept.
Reviewers: zturner, beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27094
llvm-svn: 288131
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently SLP vectorizer tries to vectorize a binary operation and dies
immediately after unsuccessful the first unsuccessfull attempt. Patch
tries to improve the situation, trying to vectorize all binary
operations of all children nodes in the binop tree.
Differential Revision: https://reviews.llvm.org/D25517
llvm-svn: 288115
|
| |
|
|
| |
llvm-svn: 288100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now expect each module's identification block to appear immediately before
the module block. Any module block that appears without an identification block
immediately before it is interpreted as if it does not have a module block.
Also change the interpretation of VST and function offsets in bitcode.
The offset is always taken as relative to the start of the identification
(or module if not present) block, minus one word. This corresponds to the
historical interpretation of offsets, i.e. relative to the start of the file.
These changes allow for bitcode modules to be concatenated by copying bytes.
Differential Revision: https://reviews.llvm.org/D27184
llvm-svn: 288098
|