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

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

[X86] Collapse FP_TO_INT16_IN_MEM/FP_TO_INT32_IN_MEM/FP_TO_INT64_IN_MEM into a single opcode using memory VT to distinquish. NFC

llvm-svn: 353798

[X86] Remove the value type operand from the floating point load/store 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

llvm-svn: 353789

llvm-svn: 353788

This avoids the unused function warning during compilation.

Differential Revision: https://reviews.llvm.org/D58082

llvm-svn: 353787

We build libc++ and libc++abi with -nodefaultlibs, so -rtlib=compiler-rt
has no effect and results in an 'argument unused during compilation'
warning which breaks the build when using -Werror. We can therefore drop
-rtlib=compiler-rt without any functional change; note that the actual
compiler-rt linking is handled by HandleCompilerRT.

Differential Revision: https://reviews.llvm.org/D58084

llvm-svn: 353786

llvm-svn: 353785

Otherwise this propagates all the way to CMake and results in an error
during configuration. We check and handle the result and report warning
separately so this is not changing the behavior.

Differential Revision: https://reviews.llvm.org/D58086

llvm-svn: 353784

The new shared pointer was assigning to the temporary instead of the
member (m_curr_frames_sp).

llvm-svn: 353783

[libFuzzer] replace slow std::mt19937 with a much faster std::minstd_rand; second attempt after failed r352732, this time with a fix for cmake

llvm-svn: 353782

llvm-svn: 353781

Summary:
This test instruments the following code with coverage, runs the fuzzer
once, and asserts that there are uncovered PCs. The ARM64 backend
optimizes this code using the `csel` (Conditional select) instruction,
which removes all branching from the resulting machine code. The test
then fails because we do not have any uncovered PCs. The easiest
solution for now is to turn off optimization for the DSOs used in this
test.

```
int DSO1(int a) {
  if (a < 123456)
    return 0;
  return 1;
}
```

rdar://47646400

Reviewers: kcc

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D58087

llvm-svn: 353780

The code checked that the first root was an appropriate distance from
the base value, but skipped checking the other roots. This could lead to
rerolling a loop that can't be legally rerolled (at least, not without
rewriting the loop in a non-trivial way).

Differential Revision: https://reviews.llvm.org/D56812

llvm-svn: 353779