| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This is the first part of an effort to add wasm binary
support across all llvm tools.
Patch by Sam Clegg
Differential Revision: https://reviews.llvm.org/D26172
llvm-svn: 288251
|
|
|
|
|
|
|
|
|
|
| |
Initial support for target shuffle constant folding in cases where all shuffle inputs are constant. We may be able to relax this and merge shuffles with only some constant inputs in the future.
I've added the helper function getTargetConstantBitsFromNode (based off a similar function in X86ShuffleDecodeConstantPool.cpp) that could be reused for other cases requiring constant vector extraction.
Differential Revision: https://reviews.llvm.org/D27220
llvm-svn: 288250
|
|
|
|
|
|
|
|
|
|
|
| |
This is the beginning of an effort to get libfuzzer working on
Windows. This is a NFC to just add some macros for platform
detection on Windows.
Patch by Marcos Pividori
Differential Revision: https://reviews.llvm.org/D27229
llvm-svn: 288249
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Further preparation for the expansion of MUL_LOHI added in D24956.
Reviewers: efriedma, RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27064
llvm-svn: 288248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The usage was previously guarded by HAVE_DLFCN. This breaks on Android with
LLVM_BUILD_STATIC as the platform does not provide a static version of libdl.
Using HAVE_DLOPEN fixes it as the code will only get used if we are actually able
to link an executable using dlopen.
Reviewers: rafael, beanz
Subscribers: tberghammer, danalbert, llvm-commits
Differential Revision: https://reviews.llvm.org/D26504
llvm-svn: 288246
|
|
|
|
|
|
| |
It is needed by LiveIntervalAnalysis.
llvm-svn: 288243
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 288235
|
|
|
|
|
|
|
|
| |
This reverts commit r288210.
The failure on the stage2 LTO build is back.
llvm-svn: 288226
|
|
|
|
|
|
| |
Storing these in the symbol table (with zero values) is just wasted space.
llvm-svn: 288225
|
|
|
|
|
|
|
|
|
|
| |
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: 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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
|
|
|
|
|
|
|
|
|
| |
This target hook was added with D19087:
https://reviews.llvm.org/D19087
Differential Revision: https://reviews.llvm.org/D27221
llvm-svn: 288206
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 288170
|
|
|
|
| |
llvm-svn: 288167
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This way, when the linker adds padding between globals, we can skip over
the zero padding bytes and reliably find the start of the next metadata
global.
llvm-svn: 288096
|
|
|
|
|
|
|
|
|
|
|
|
| |
branches
Reviewers: arsenm
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: https://reviews.llvm.org/D23417
llvm-svn: 288095
|
|
|
|
|
|
|
|
| |
It looks like this logic was duplicated long ago and the GCC side of
things has grown additional functionality. We need ${:uid} at least to
generate unique MS inline asm labels (PR23715), so expose these.
llvm-svn: 288092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
load-elimination
This includes the intervening store and the load/store that we're trying
to forward from in the optimization remark for the missed load
elimination.
This is hooked up under a new mode in ORE that allows for compile-time
budget for a bit more analysis to print more insightful messages. This
mode is currently enabled for -fsave-optimization-record (-Rpass is
trickier since it is controlled in the front-end).
With this we can now print the red remark in 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#L446
Differential Revision: https://reviews.llvm.org/D26490
llvm-svn: 288090
|
|
|
|
| |
llvm-svn: 288088
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the checking for both the MachO::fat_header and the
MachO::fat_arch struct values in the constructor for
MachOUniversalBinary. Such that when the constructor
for ObjectForArch is called it can assume the values in
the MachO::fat_arch for the offset and size are contained
in the file after the MachOUniversalBinary constructor
is called for the Parent.
llvm-svn: 288084
|