llvm-svn: 358942

This reverts r358910 (git commit 2b744665)

While this patch *seems* trivial and safe and correct, it is not. The
copies are actually load bearing copies. You can observe this with MSan
or other ways of checking for use-after-destroy, but otherwise this may
result in ... difficult to debug inexplicable behavior.

I suspect the issue is that the debug location is used after the
original reference to it is removed. The metadata backing it gets
destroyed as its last references goes away, and then we reference it
later through these const references.

llvm-svn: 358940

was still stat'ing the possibly-dSYM FileSpec before I
(more cheaply) checked the filepath for telltale dSYM
components.
<rdar://problem/50086007> 

llvm-svn: 358939

which reads the python files in a dSYM bundle, to check that the
SymbolFile is actually a dSYM bundle filepath; delay any fetching
of the ScriptInterpreter until after we've done that check.

When debugging a binary without a dSYM on darwin systems, the
SymbolFile we fetch is actually the ObjectFile -- so we would do
an unnecessary trip into Python land and stat around the filesystem
looking for a python file to read in.  There's no reason to do any
of this unless the SymbolFile's file path includes the .dSYM bundle
telltale path components.

<rdar://problem/50065315> 

llvm-svn: 358938

Otherwise, we don't seem to get the DYLD_LIBRARY_PATH set up correctly
and the tests are run against the system libc++abi dylib.

llvm-svn: 358937

This is a more generic solution; while the sanitizer support can be used
only for sanitizer instrumented builds, the multilib support can be used
to build other variants such as noexcept which is what we would like to use
in Fuchsia.

The name CMake target name uses the target name, same as for the regular
runtimes build and the name of the multilib, concatenated with '+'. The
libraries are installed in a subdirectory named after the multilib.

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

llvm-svn: 358935

llvm-svn: 358933

llvm-svn: 358932

Currently to opt in to debug_names in DWARFv5, the IR must contain
'nameTableKind: Default' which also enables debug_pubnames.

Instead, only allow one of {debug_names, apple_names, debug_pubnames,
debug_gnu_pubnames}.

nameTableKind: Default gives debug_names in DWARFv5 and greater,
debug_pubnames in v4 and earlier - and apple_names when tuning for lldb
on MachO.
nameTableKind: GNU always gives gnu_pubnames

llvm-svn: 358931

This was supposed to be NFC, but the change in SDLoc
definitions causes instruction scheduling changes.

There's nothing x86-specific in this code, and it can
likely be used from DAGCombiner's simplifyVBinOp().

llvm-svn: 358930

In the process of hoisting the LoadScriptingResourceForModule
out of Target::ModuleAdded and into Target::ModulesDidLoad,
I had ModulesDidLoad fetching the Target's entire image list
and look for scripting resources in those -- instead of only
looking for scripting resources in the modules that had
been added to the target's image list.

<rdar://problem/50065315> 

llvm-svn: 358929

This moves the links to the C++ and Python API docs up to the main page.
As of now the links are still broken [1], but at least this will prevent
the additional frustration of searching for the links only to find out
they're broken.

[1] http://lists.llvm.org/pipermail/lldb-dev/2019-April/014992.html

llvm-svn: 358928

llvm-svn: 358927

llvm-svn: 358926

llvm-svn: 358924

Summary:
- Only apply packed literal `op_sel_hi` skipping on operands requiring
  packed literals. Even an instruction is `packed`, it may have operand
  requiring non-packed literal, such as `v_dot2_f32_f16`.

Reviewers: rampitec, arsenm, kzhuravl

Subscribers: jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 358922

When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.

This patch teaches dsymutil to look for DW_TAG_imported_modules and
records all references to parseable Swift ingterfrace files and copies
them to

  a.out.dSYM/Contents/Resources/<Arch>/<ModuleName>.swiftinterface

<rdar://problem/49751748>

llvm-svn: 358921

If we have a store to a piece of memory which is known constant, then we know the store must be storing back the same value. As a result, the store (or memset, or memmove) must either be down a dead path, or a noop. In either case, it is valid to simply remove the store.

The motivating case for this involves a memmove to a buffer which is constant down a path which is dynamically dead.

Note that I'm choosing to implement the less aggressive of two possible semantics here. We could simply say that the store *is undefined*, and prune the path. Consensus in the review was that the more aggressive form might be a good follow on change at a later date.

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

llvm-svn: 358919

llvm-svn: 358918

Previously, it was only documented by `-cc1 -help`, so people weren't
aware of it, as discussed in D60732.

Reviewed By: Charusso, NoQ

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

llvm-svn: 358917

Deallocating the data recorder in during the ::Keep() operation causes
problems down the line when exiting the debugger. The command
interpreter still holds a pointer to the now deallocated object and has
no way to know it no longer exists. This is exactly what the m_record
flag was meant for, although it wasn't hooked up properly either.

llvm-svn: 358916

This enables the use of this script from other build systems like
GN which don't support post-build actions as well as for static
archives.

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

llvm-svn: 358915

Summary:
This test was added to verify that createUniqueEntity() does
not enter an infinite loop when all possible names are taken. However,
it also checked that all possible names are generated, which is flaky
(because the names are generated randomly). This change increases the
number of attempts we make to make flakes exceedingly
unlikely (3.88e-62).

Reviewers: fedor.sergeev, rsmith

Reviewed By: fedor.sergeev

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 358914

In the process, use the existing masked.load combine which is slightly stronger, and handles a mix of zero and undef elements in the mask.  

llvm-svn: 358913

llvm-svn: 358912

Summary:
I ran into some issues after rOMP355687, where __atomic_fetch_add was
being used incorrectly on x86, and this turns out to be caused by the
following added conditionals:

```
#if defined(KMP_ARCH_MIPS)
```

The problem is, these macros are always defined, and are either 0 or 1
depending on the architecture.  E.g. the correct way to test for MIPS
is:

```
#if KMP_ARCH_MIPS
```

Reviewers: petarj, jlpeyton, Hahnfeld, AndreyChurbanov

Reviewed By: petarj, AndreyChurbanov

Subscribers: AndreyChurbanov, sdardis, arichardson, atanasyan, jfb, jdoerfert, openmp-commits, llvm-commits

Tags: #openmp

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

llvm-svn: 358911

llvm-svn: 358910

These are inserted after branch relaxation, and for some reason it's
decided to put them in the long branch expansion block. It's probably
not great to rely on the source block address, so this should probably
be switched to being PC relative instead of relying on the block
address

llvm-svn: 358909

Due to MSVC's decision to encode `wchar_t` as UTF-16, it rejects wide
character/string literals that expect a character value greater than
`\xffff`. UTF-16 `wchar_t` is clearly non-conforming, given that the
standard requires wchar_t to be capable of representing all characters
in the supported wide character execution sets, but rejecting e.g.
`\x40003` is a reasonably sane compromise given that encoding choice:
there's an expectation that `\xFOO` produces a single character in the
resulting literal. Consequently `L'\x40003'`/`L"\x40003"` are ill-formed
literals on MSVC. `L'\U00040003'` is a high surrogate (and produces a
warning about ignoring the "second character" in a multi-character
literal), and `L"\U00040003"` is a perfectly-valid `const wchar_t[3]`.

This change updates these tests to use universal-character-names instead
of raw values for the intended character values, which technically makes
them portable even to implementations that don't use a unicode
transformation format encoding for their wide character execution
character set. The two-character literal `L"\u1005e"` is awkward - the
`e` looks like part of the UCN's hex encoding - but necessary to compile
in '03 mode since '03 didn't allow UCNs to be used for members of the
basic execution character set even in character/string literals.

I've also eliminated the extraneous `\x00` "bonus null-terminator" in
some of the string literals which doesn't affect the tested behavior.

I'm sorry about using `*L"\U00040003"` in `conversions.string/to_bytes.pass.cpp`,
but it's correct for platforms with 32-bit wchar_t, *and* doesn't
trigger narrowing warnings as did the prior `CharT(0x40003)`.

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

llvm-svn: 358908

llvm-svn: 358907

llvm-svn: 358906

[ASTMatchers] Introduce Objective-C matchers `isClassMessage`, `isClassMethod`, and `isInstanceMethod`

Summary:
isClassMessage is an equivalent to isInstanceMessage for ObjCMessageExpr, but matches message expressions to classes.

isClassMethod and isInstanceMethod check whether a method declaration (or definition) is for a class method or instance method (respectively).

Contributed by @mywman!

Reviewers: benhamilton, klimek, mwyman

Reviewed By: benhamilton, mwyman

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 358904

Back in August, r340525 introduced a dependency on the assumption
cache tracker in the ipsccp pass, but that commit missed a call to
INITIALIZE_PASS_DEPENDENCY, which leaves the assumption cache
improperly registered if SCCP is the only thing that pulls it in.

llvm-svn: 358903

Fix the test to run it really in SPMD mode without runtime. Previously
it was run in SPMD + full runtime mode and does not allow to cehck the
functionality correctly.

llvm-svn: 358902

Currently, we do not expose BPI to loop passes at all. In the old pass manager, we appear to have been ignoring the fact that LCSSA and/or LoopSimplify didn't preserve BPI, and making it available to the following loop passes anyways.  In the new one, it's invalidated before running any loop pass if either LCSSA or LoopSimplify actually make changes. If they don't make changes, then BPI is valid and available.  So, we go ahead and teach LCSSA and LoopSimplify how to preserve BPI for consistency between old and new pass managers.

This patch avoids an invalidation between the two requires in the following trivial pass pipeline:
opt -passes="requires<branch-prob>,loop(no-op-loop),requires<branch-prob>"
(when the input file is one which requires either LCSSA or LoopSimplify to canonicalize the loops)

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

llvm-svn: 358901

to CallInst.

The issue was raised here: https://reviews.llvm.org/D60903#1472783

The function Instruction::updateProfWeight is only used for CallInst in
profile update. From the current interface, it is very easy to think that
the function can also be used for branch instruction. However, Branch
instruction does't need the scaling the function provides for
branch_weights and VP (value profile), in addition, scaling may introduce
inaccuracy for branch probablity.

The patch moves the function updateProfWeight from Instruction class to
CallInst to remove the confusion. The patch also changes the scaling of
branch_weights from a loop to a block because we know that ProfileData
for branch_weights of CallInst will only have two operands at most.

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

llvm-svn: 358900

We can't (currently) meaningfully resolve certain types of relocations
against undefined data symbols.  Previously when `--allow-undefined` was
used we were treating such relocation much like weak data symbols and
simply inserting zeros.  This change turns such use cases in to an
error.

This means that `--allow-undefined` is no longer effective for data
symbols.

Fixes https://bugs.llvm.org/show_bug.cgi?id=40364

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

llvm-svn: 358899

Summary:
* Removed a member that was only used during construction.
* Use range-based for iteration when accessing the result of the search.
* Require an `ObjCMethodDecl` reference upon construction of an
* Constify.

Reviewers: rjmccall

Reviewed By: rjmccall

Subscribers: llvm-commits

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

llvm-svn: 358898

llvm-svn: 358897

llvm-svn: 358896