| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 353855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The SMULO/UMULO DAG nodes, when not directly supported by the target,
expand to a multiplication twice as wide. In case that the resulting
type is not legal, the legalizer cannot directly call the intrinsic
with the wide arguments; instead, it "pre-lowers" them by splitting
them in halves.
rL283203 made sure that on big endian targets, the legalizer passes
the argument halves in the correct order. It did not do the same
for the return value halves because the existing code used a hack;
it put an illegal type into DAG and hoped that nothing would break
and it would be correctly lowered elsewhere.
rL307207 fixed this, handling return value halves similar to how
argument handles are handled, but did not take big-endian targets
into account.
This commit fixes the expansion on big-endian targets, such as
the out-of-tree OR1K target.
Reviewers: eli.friedman, vadimcn
Subscribers: george-hopkins, efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D45355
llvm-svn: 353854
|
|
|
|
|
|
|
| |
We're using static libc++ for the second stage which requires explicitly
linking -ldl and -lpthread.
llvm-svn: 353853
|
|
|
|
| |
llvm-svn: 353852
|
|
|
|
| |
llvm-svn: 353851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A few places in the library seem to behave unexpectedly when the library
is compiled or used with exceptions disabled. For example, not throwing
an exception when a pointer is NULL can lead us to dereference the pointer
later on, which is UB. This patch fixes such occurences.
It's hard to tell whether there are other places where the no-exceptions
mode misbehaves like this, because the replacement for throwing an
exception does not always seem to be abort()ing, but at least this
patch will improve the situation somewhat.
See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57761
llvm-svn: 353850
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A follow up to the intial patch that unblocked linking against libgcc.
For lld we don't need to bother tracking which objects have got based small
code model relocations. This is due to the fact that the compilers on
powerpc64 use the .toc section to generate indirections to symbols (rather then
using got relocations) which keeps the got small. This makes overflowing a
small code model got relocation very unlikely.
Differential Revision: https://reviews.llvm.org/D57245
llvm-svn: 353849
|
|
|
|
| |
llvm-svn: 353848
|
|
|
|
|
|
|
|
|
| |
We need to clear the kill flags on both SingleValReg and OldReg, to ensure they remain
conservatively correct.
Differential Revision: https://reviews.llvm.org/D58114
llvm-svn: 353847
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
An empty dwo_id indicates a degenerate .dwo file that should not have been generated in the first place. Instead of discovering this error later when merging with another degenerate .dwo file, print an error immediately when noticing an unset dwo_id, including the filename of the offending file.
Test case created by compiling a trivial file w/ `-fno-split-dwarf-inlining -gmlt -gsplit-dwarf -c` prior to r353771
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: jdoerfert, aprantl, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58085
llvm-svn: 353846
|
|
|
|
|
|
| |
We could deal with it, but there's no real point.
llvm-svn: 353845
|
|
|
|
|
|
|
| |
I don't think this matters since the values should all be exactly
representable.
llvm-svn: 353844
|
|
|
|
| |
llvm-svn: 353843
|
|
|
|
| |
llvm-svn: 353842
|
|
|
|
|
|
|
|
|
| |
This enables the function to be called with a StringRef without jumping
through any hoops. I rename the function to "PutStringAsRawHex8" to
honor the extended interface. I also remove ".c_str()" from any calls to
this function I could find.
llvm-svn: 353841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: See the added test for a repro.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58111
llvm-svn: 353840
|
|
|
|
| |
llvm-svn: 353839
|
|
|
|
|
|
| |
Amends r353837 which renamed the diagnostics to conflict.
llvm-svn: 353838
|
|
|
|
| |
llvm-svn: 353837
|
|
|
|
| |
llvm-svn: 353836
|
|
|
|
| |
llvm-svn: 353832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Salvaging a redundant load instruction into a debug expression hides a
memory read from optimisation passes. Passes that alter memory behaviour
(such as LICM promoting memory to a register) aren't aware of these debug
memory reads and leave them unaltered, making the debug variable location
point somewhere unsafe.
Teaching passes to know about these debug memory reads would be challenging
and probably incomplete. Finding dbg.value instructions that need to be fixed
would likely be computationally expensive too, as more analysis would be
required. It's better to not generate debug-memory-reads instead, alas.
Changed tests:
* DeadStoreElim: test for salvaging of intermediate operations contributing
to the dead store, instead of salvaging of the redundant load,
* GVN: remove debuginfo behaviour checks completely, this behaviour is still
covered by other tests,
* InstCombine: don't test for salvaged loads, we're removing that behaviour.
Differential Revision: https://reviews.llvm.org/D57962
llvm-svn: 353824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a preparatory change for removing the code from
DebugHandlerBase::beginFunction() which changes the starting label for
the first non-overlapping DBG_VALUEs of parameters to the beginning of
the function. It does that to be able to show parameters when entering a
function. However, that code does not consider what defines the values,
which can result in the ranges for the debug values starting before
their defining instructions. That code is removed in a follow-up patch.
When prologue code is inserted, it leads to DBG_VALUEs that start
directly in the entry block being moved down after the prologue
instructions. This patch fixes that by stashing away DBG_VALUEs for
parameters before emitting the prologue, and then reinserts them at the
start of the block. This assumes that there is no target that somehow
clobbers parameter registers in the frame setup; there is no such case
in the lit tests at least.
See PR40188 for more information.
Reviewers: aprantl, dblaikie, rnk, jmorse
Reviewed By: aprantl
Subscribers: bjope, llvm-commits
Tags: #debug-info
Differential Revision: https://reviews.llvm.org/D57510
llvm-svn: 353823
|
|
|
|
| |
llvm-svn: 353821
|
|
|
|
|
|
|
| |
Update numbers after 353817.
This was extensively benchmarked in https://reviews.llvm.org/D54889
llvm-svn: 353820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds functions for managing fibers:
__tsan_get_current_fiber()
__tsan_create_fiber()
__tsan_destroy_fiber()
__tsan_switch_to_fiber()
__tsan_set_fiber_name()
See the added tests for use examples.
Author: yuri (Yuri Per)
Reviewed in: https://reviews.llvm.org/D54889
llvm-svn: 353817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Logic in `getInsertPointForUses` doesn't account for a corner case when `Def`
only comes to a Phi user from unreachable blocks. In this case, the incoming
value may be arbitrary (and not even available in the input block) and break
the loop-related invariants that are asserted below.
In fact, if we encounter this situation, no IR modification is needed. This
Phi will be simplified away with nearest cleanup.
Differential Revision: https://reviews.llvm.org/D58045
Reviewed By: spatel
llvm-svn: 353816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: AMD64 psABI says: "The pr_data field of each property contains a 4-byte unsigned integer." Thus we don't need to handle 8-byte pr_data.
Reviewers: mike.dvoretsky, grimar, craig.topper, xiangzhangllvm, hjl.tools
Reviewed By: grimar
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58103
llvm-svn: 353815
|
|
|
|
|
|
|
|
|
|
|
| |
Current implementation takes "Number of needed versions" from DT_VERNEEDNUM
dynamic tag entry. Though it would be a bit simpler to take it from sh_info
section header field directly:
https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html
Differential revision: https://reviews.llvm.org/D58048
llvm-svn: 353814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function `LI.erase` has some invariants that need to be preserved when it
tries to remove a loop which is not the top-level loop. In particular, it
requires loop's preheader to be strictly in loop's parent. Our current logic
of deletion of dead blocks may erase the information about preheader before we
handle the loop, and therefore we may hit this assertion.
This patch changes the logic of loop deletion: we make them top-level loops
before we actually erase them. This allows us to trigger the simple branch of
`erase` logic which just detatches blocks from the loop and does not try to do
some complex stuff that need this invariant.
Thanks to @uabelho for reporting this!
Differential Revision: https://reviews.llvm.org/D57221
Reviewed By: fedor.sergeev
llvm-svn: 353813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The two classes contained a lot of duplicated code, but there wasn't a
good place to factor it to. It couldn't be the base Platform class,
since we also have platforms which are only remote (such as
PlatformGDBRemoteServer), and so it did not make sense for those to have
an m_remote_platform member.
This patch creates a new class, RemoteAwarePlatform, which can serve as
a base class for platforms which can both serve as a host, and forward
actions to a remote system. It is motivated partly by D56232 (which was
about to add a bunch of additional duplicated methods), and partly by my
own need to modify a function which happens to be implemented in both
places identically.
The patch moves the methods which are trivially identical in the two
classes into the common base class, there were one or two more methods
which could probably be merged into one, but this wasn't completely
trivial, so I did not attempt to do that now.
Reviewers: jingham, zturner, clayborg, asmith
Subscribers: emaste, mgorny, Hui, lldb-commits
Differential Revision: https://reviews.llvm.org/D58052
llvm-svn: 353812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELFYAML.h contains a `Section` class which is a base for a few other
sections classes that are used for mapping different section types.
`Section` has a `StringRef Info` field used for storing sh_info.
At the same time, sh_info has very different meanings for sections and
cannot be processed in a similar way generally,
for example ELFDumper does not handle it in `dumpCommonSection`
but do that in `dumpGroup` and `dumpCommonRelocationSection` respectively.
At this moment, we have and handle it as a string, because that was possible for
the current use case. But also it can simply be a number:
For SHT_GNU_verdef is "The number of version definitions within the section."
The patch moves `Info` field out to be able to have it as a number.
With that change, each class will be able to decide what type and purpose
of the sh_info field it wants to use.
I also had to edit 2 test cases. This is because patch fixes a bug. Previously we
accepted yaml files with Info fields for all sections (for example, for SHT_DYNSYM too).
But we do not handle it and the resulting objects had zero sh_info fields set for
such sections. Now it is accepted only for sections that supports it.
Differential revision: https://reviews.llvm.org/D58054
llvm-svn: 353810
|
|
|
|
| |
llvm-svn: 353809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch makes virtual bases to be added in the correct order to the bases
list. It is important because `VTableContext` (`MicrosoftVTableContext` in our
case) uses then the order of virtual bases in the list to restore the virtual
table indexes. These indexes are used then to resolve the layout of the virtual
bases.
We haven't enough information about offsets of virtual bases regarding to the
object (moreover, in a common case we can't rely on such information, see the
example here: https://reviews.llvm.org/D53506#1272306 ), but there should be
enough information to restore the layout of the virtual bases from the indexes
in runtime. After D53506 this information is used whenever possible, so there
should be no problems with virtual bases' fields reading.
Reviewers: zturner, rnk, stella.stamenova
Subscribers: abidh, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56904
llvm-svn: 353806
|
|
|
|
|
|
|
|
|
| |
This change is preparation for fiber support.
Author: yuri (Yuri Per)
Reviewed in: https://reviews.llvm.org/D58104
llvm-svn: 353805
|
|
|
|
| |
llvm-svn: 353804
|
|
|
|
|
|
|
|
|
|
|
| |
Utility function that we use for blocks deletion always unconditionally removes
one-input Phis. In LoopSimplifyCFG, it can lead to breach of LCSSA form.
This patch alters this function to keep them if needed.
Differential Revision: https://reviews.llvm.org/D57231
Reviewed By: fedor.sergeev
llvm-svn: 353803
|
|
|
|
|
|
|
|
| |
pointer arguments.
This matches what gcc does and what was suggested by rnk in PR20670.
llvm-svn: 353802
|
|
|
|
| |
llvm-svn: 353801
|
|
|
|
| |
llvm-svn: 353800
|
|
|
|
| |
llvm-svn: 353799
|
|
|
|
|
|
| |
a single opcode using memory VT to distinquish. NFC
llvm-svn: 353798
|
|
|
|
|
|
|
|
| |
MemIntrinsicSDNodes. Use the MemoryVT instead. NFCI
We already have the memory VT, we can just match from that during isel.
llvm-svn: 353797
|
|
|
|
|
|
|
| |
When performing runtimes build, dependencies like clang and
clang-headers aren't available. This was accidentally omitted in D57992.
llvm-svn: 353796
|
|
|
|
|
|
|
|
| |
This commit removes redundant calls to smart pointer’s ::get() method.
https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html
llvm-svn: 353795
|
|
|
|
| |
llvm-svn: 353794
|
|
|
|
|
|
|
| |
The CMake change associated with this comment was removed but the
comment got left behind. Add a newline instead.
llvm-svn: 353793
|
|
|
|
| |
llvm-svn: 353792
|
|
|
|
| |
llvm-svn: 353791
|
|
|
|
|
|
|
|
|
| |
Ensure that HandleLLVMOptions adds all necessary required flags,
including -Wno-error when building with LLVM_ENABLE_WERROR enabled.
Differential Revision: https://reviews.llvm.org/D58092
llvm-svn: 353790
|