| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment, support for runtime debug output using the
OMPTARGET_DEBUG=1 environment variable is only available with
CMAKE_BUILD_TYPE=Debug builds. The patch allows setting it independently
using the LIBOMPTARGET_ENABLE_DEBUG option, which is enabled by default
depending on CMAKE_BUILD_TYPE. That is, unless this option is set
explicitly, nothing changes. This is the same mechanism used by LLVM for
LLVM_ENABLE_ASSERTIONS.
This patch also removes adding -g -O0 in debug builds, it should be
handled by cmake's CMAKE_{C|CXX}_FLAGS_DEBUG configuration option.
Idea by Hal Finkel
Differential Revision: https://reviews.llvm.org/D55952
llvm-svn: 356998
|
| |
|
|
|
|
|
| |
This instruction is unused and not needed.
Review: Ulrich Weigand.
llvm-svn: 356997
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various SelectionDAG non-combine operations (e.g. the getNode smart
constructor and legalization) may leave dangling nodes by applying
optimizations or not fully pruning unused result values. This can
result in nodes that are never added to the worklist and therefore can
not be pruned.
Add a node inserter as the current node deleter to make sure such
nodes have the chance of being pruned.
Many minor changes, mostly positive.
llvm-svn: 356996
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59584
llvm-svn: 356995
|
| |
|
|
|
|
| |
are enabled
llvm-svn: 356994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After D59297, the TypePair class kind of lost its purpose as it was no
longer a "pair". This finishes the job started in that patch and deletes
the class altogether. All usages have been updated to use CompilerType
class directly.
Reviewers: clayborg, jingham, zturner
Subscribers: mehdi_amini, dexonsmith, jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59414
llvm-svn: 356993
|
| |
|
|
|
|
|
|
| |
This is the next step in moving the minidump parsing into llvm. I remove
the minidump structures already defined in the llvm Object library and
convert our parser to use those. NFC.
llvm-svn: 356992
|
| |
|
|
|
|
|
|
|
| |
Adds two patterns to improve the codegen of GPR value comparisons with small
constants. Instead of first loading the constant into another register and then
doing an XOR of those registers, these patterns directly use the constant as an
XORI immediate.
llvm-svn: 356990
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This helps us relax the extension of a lot of scalar elements before they are inserted into a vector.
Its exposes an issue in DAGCombiner::convertBuildVecZextToZext as some/all the zero-extensions may be relaxed to ANY_EXTEND, so we need to handle that case to avoid a couple of AVX2 VPMOVZX test regressions.
Once this is in it should be easier to fix a number of remaining failures to fold loads into VBROADCAST nodes.
Differential Revision: https://reviews.llvm.org/D59484
llvm-svn: 356989
|
| |
|
|
|
|
|
|
|
|
| |
DenseMap iteration order is not guaranteed, use MapVector instead.
Fix provided by srhines.
Differential Revision: https://reviews.llvm.org/D59807
llvm-svn: 356988
|
| |
|
|
| |
llvm-svn: 356987
|
| |
|
|
|
|
|
|
|
|
|
| |
Let lists have an trailing comma to allow cleaner diffs e.g:
def : Features<[FeatureA,
FeatureB,
]>;
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D59247
llvm-svn: 356986
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When one mistakenly specifies 'def' instead of using 'defm',
the error message is quite misleading: 'Couldn't find class..'
Instead, it should recommend using defm if the multiclass of
same name exists.
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D59294
llvm-svn: 356985
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D59760
llvm-svn: 356984
|
| |
|
|
| |
llvm-svn: 356983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes GNU binutils not reject the libraries outright.
GNU ld handles weak externals slightly differently though, so it
can't use them for aliases in import libraries, but this makes GNU
ld able to use the rest of the import libraries.
LLD accepted object files with machine type 0 aka
IMAGE_FILE_MACHINE_UNKNOWN.
Differential Revision: https://reviews.llvm.org/D59742
llvm-svn: 356982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RISC-V assembler needs the target ABI because it defines a flag of the ELF
file, as described in [1].
Make clang (the driver) to pass the target ABI to -cc1as in exactly the same
way it does for -cc1.
Currently -cc1as knows about -target-abi but is not handling it. Handle it and
pass it to the MC layer via MCTargetOptions.
[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#file-header
Differential Revision: https://reviews.llvm.org/D59298
llvm-svn: 356981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rL356312 changed the return type of emplace_back from void to reference.
Update the tests to check the behavior.
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59809
llvm-svn: 356980
|
| |
|
|
|
|
|
|
|
|
| |
in the DAG for the topological sort.
We were using OrigNBits, but that put all the nodes before the node we used to start the control computation. This caused some node earlier than the sequence we inserted to be selected before the sequence we created. We want our new sequence to be selected first since it depends on OrigNBits.
I don't have a test case. Found by reviewing the code.
llvm-svn: 356979
|
| |
|
|
|
|
|
|
| |
the BEXTR at Node's position in the DAG for the topological sort.
We were using OrigNBits, but that doesn't guarantee that it will be selected before the nodes that make up X.
llvm-svn: 356978
|
| |
|
|
|
|
| |
We do fold loads right below this.
llvm-svn: 356977
|
| |
|
|
|
|
|
|
|
| |
Do not pipe binary data between processes in lit tests this time,
since it turns out that can break on Windows.
This reverts commit 84c8652fc3085155d0f9c355455e5a797c6d9db6.
llvm-svn: 356975
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We shouldn't prevent user from disabling XPC framework build on Darwin.
However, by keeping it on by default our CI systems also test
it by default on macOS.
Based on user request:
http://lists.llvm.org/pipermail/cfe-dev/2019-March/061778.html
Differential Revision: https://reviews.llvm.org/D59808
llvm-svn: 356974
|
| |
|
|
|
|
|
|
| |
Within the MatchFPUWaitAlias function, Operands[0] is potentially overwritten leading to &Op referencing a deleted object. To fix this, assign the reference after the function.
Differential Revision: https://reviews.llvm.org/D57376
llvm-svn: 356973
|
| |
|
|
|
|
|
|
|
|
| |
This error can only happen if an unfinished operation is at Eof.
Patch by Brandon Jones
Differential Revision: https://reviews.llvm.org/D57379
llvm-svn: 356972
|
| |
|
|
|
|
|
|
|
| |
The python plugin uses wrappers generated by swig. For the symbols to be
available, we'd need to link against liblldb, which is not an option
because the symbols could conflict with the static library we are
testing. Instead we define the symbols ourselves in the unit test.
llvm-svn: 356971
|
| |
|
|
|
|
|
|
|
| |
We want to distribute only a single archive so -lc++ does the right
thing and users don't have to explicitly link -lc++abi and -lunwind.
Differential Revision: https://reviews.llvm.org/D59803
llvm-svn: 356970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r356634 didn't fix all the problems caused by r356222 - even though simple
constructors involving transparent init-list expressions are now evaluated
precisely, many more complicated constructors aren't, for other reasons.
The attached test case is an example of a constructor that will never be
evaluated precisely - simply because there isn't a constructor there (instead,
the program invokes run-time undefined behavior by returning without a return
statement that should have constructed the return value).
Fix another part of the problem for such situations: evaluate transparent
init-list expressions transparently, so that to avoid creating ill-formed
"transparent" nonloc::CompoundVals.
Differential Revision: https://reviews.llvm.org/D59622
llvm-svn: 356969
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This should address remaining issues discussed in PR36555.
Currently R_GOT*_FROM_END are exclusively used by x86 and x86_64 to
express relocations types relative to the GOT base. We have
_GLOBAL_OFFSET_TABLE_ (GOT base) = start(.got.plt) but end(.got) !=
start(.got.plt)
This can have problems when _GLOBAL_OFFSET_TABLE_ is used as a symbol, e.g.
glibc dl_machine_dynamic assumes _GLOBAL_OFFSET_TABLE_ is start(.got.plt),
which is not true.
extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden;
return _GLOBAL_OFFSET_TABLE_[0]; // R_X86_64_GOTPC32
In this patch, we
* Change all GOT*_FROM_END to GOTPLT* to fix the problem.
* Add HasGotPltOffRel to denote whether .got.plt should be kept even if
the section is empty.
* Simplify GotSection::empty and GotPltSection::empty by setting
HasGotOffRel and HasGotPltOffRel according to GlobalOffsetTable early.
The change of R_386_GOTPC makes X86::writePltHeader simpler as we don't
have to compute the offset start(.got.plt) - Ebx (it is constant 0).
We still diverge from ld.bfd (at least in most cases) and gold in that
.got.plt and .got are not adjacent, but the advantage doing that is
unclear.
Reviewers: ruiu, sivachandra, espindola
Subscribers: emaste, mehdi_amini, arichardson, dexonsmith, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59594
llvm-svn: 356968
|
| |
|
|
|
|
| |
This should fix the Windows bot (fingers crossed).
llvm-svn: 356967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lld's mark-sweep garbage collector was written in the visitor pattern.
There are functions that traverses a given graph, and the functions calls
callback functions to dispatch according to node type.
The code was originaly pretty simple, and lambdas worked pretty
well. However, as we add more features to the garbage collector, that became
more like a callback hell. We now have a callback function that wraps
another callback function, for example. It is not easy to follow the flow of
the control.
This patch rewrites it as a regular class. What was once a lambda is now a
regular class member function. I think this change fixes the readability
issue.
No functionality change intended.
Differential Revision: https://reviews.llvm.org/D59800
llvm-svn: 356966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compiling with -polly-target=hybrid was causing Polly to occur two times
in the pipeline. The reason was how the ManagedMemoryRewritePass was
registered in the pass manager. ManagedMemoryRewritePass being a
ModulePass was forcing all previous passes to get recomputed. This
commit avoids Polly to appear two times in the pipeline registering the
ManagedMemoryRewritePass later in the pass manager.
Patch by Lorenzo Chelini <l.chelini@icloud.com>
Differential Revision: https://reviews.llvm.org/D59263
llvm-svn: 356965
|
| |
|
|
|
|
|
|
|
|
| |
The intention is to add metadata to direct call sites of functions
marked with __declspec(allocator), which will ultimately result in some
S_HEAPALLOCSITE debug info records when emitting codeview.
This is a piece of PR38491
llvm-svn: 356964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should hopefully lead to minor improvements in code generation, and
more accurate spill/reload comments in assembly.
Also fix isLoadFromStackSlotPostFE/isStoreToStackSlotPostFE so they
don't lead to misleading assembly comments for merged memory operands;
this is technically orthogonal, but in practice the relevant memory
operand lists don't show up without this change.
Differential Revision: https://reviews.llvm.org/D59713
llvm-svn: 356963
|
| |
|
|
|
|
| |
This file was missing the LLVM license header
llvm-svn: 356962
|
| |
|
|
| |
llvm-svn: 356961
|
| |
|
|
| |
llvm-svn: 356960
|
| |
|
|
| |
llvm-svn: 356959
|
| |
|
|
|
|
|
|
| |
This reverts r356149.
This is crashing on rocBLAS.
llvm-svn: 356958
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
are dependent
Bail-out of CheckArrayAccess when the types of the base expression before
and after eventual casts are dependent. We will get another chance to check
for array bounds during instantiation. Fixes PR41087.
Differential Revision: https://reviews.llvm.org/D59776
Reviewed By: efriedma
llvm-svn: 356957
|
| |
|
|
|
|
|
| |
Subregister indexes are not used for physical register operands, so
isFullCopy is implied by the physical register check.
llvm-svn: 356956
|
| |
|
|
|
|
|
|
| |
Without a VALU instruction in the return block, these were mostly
testing the path to delete exec mask code before s_endpgm rather than
the end cf handling.
llvm-svn: 356955
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is generally more readable due to the way the assembler aliases
work.
(This causes a lot of test changes, but it's not really as scary as it
looks at first glance; it's just mechanically changing a bunch of checks
for orr to check for mov instead.)
Differential Revision: https://reviews.llvm.org/D59720
llvm-svn: 356954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't (don't want to) honor the same set of "-fuse-ld" flags with
WebAssembly since the ELF linkers (ld.lld, ld.gnu, etc) don't work with
wasm object files.
Instead we implement our own linker finding logic, similar or other
non-ELF platforms like MSVC.
We've had a few issues with CLANG_DEFAULT_LINKER overriding the
WebAssembly linker which doesn't make sense since there is no generic
linker that can handle WebAssembly today.
Differential Revision: https://reviews.llvm.org/D59743
llvm-svn: 356953
|
| |
|
|
|
|
|
|
| |
These were defaulting to true, but they are just wrappers around bit
operations. This avoids regressions in the exec mask optimization
passes in a future commit.
llvm-svn: 356952
|
| |
|
|
|
|
|
|
| |
This reverts commit 312ab05887d0e2caa29aaf843cefe39379a98d36.
My commit broke the build; I will revert and find out what happened.
llvm-svn: 356951
|
| |
|
|
| |
llvm-svn: 356950
|
| |
|
|
|
|
|
|
| |
This reverts commit 5aa7478a55fa86dae45913b82bd05ed32d9c0973.
Some things are broken; I will fix and try to commit again.
llvm-svn: 356949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add a binding to Function::lookupIntrinsicID so clients don't have to go searching the ID table themselves.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59697
llvm-svn: 356948
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59494
llvm-svn: 356947
|