Fix -DBUILD_SHARED_LIBS=ON build after rL362160

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

llvm-svn: 362180

Defer capture initialization for captured regions until after we've left
the captured region scope.

This removes a case where we would build expressions (and mark
declarations odr-used) in the wrong scope.

Remove the now-unused 'capture initializer' field on sema::Capture
(except for 'this' captures, which still need to be cleaned up).

No functionality change intended (except that we now very slightly more
precisely determine whether we need to use a capture or not when another
captured region encloses an OpenMP captured region).

llvm-svn: 362179

Defer capture initialization for blocks until after we've left the
function scope.

This removes one of the last few cases where we build expressions in the
wrong function scope context. No functionality change intended.

llvm-svn: 362178

Make CPlusPlusNameParser robust against nullptr StringRefs.

There is likely also an underlying bug in all code that calls
CPlusPlusNameParser with nullptrs, but this patch can also stand for
itself.

rdar://problem/49072829

llvm-svn: 362177

[clangd] clang-format SymbolCollector.cpp

llvm-svn: 362176

[X86] Remove result type constraints from the extloadv2f32/extloadv4f32/extloadv8f32 PatFrags. NFC

The result types aren't mentioned in the pattern name so really shouldn't be in the PatFrags.

The users of these either have their own type constraint or rely on the type constranit system to realize the only legal extend would be to f64.

llvm-svn: 362175

MISched: Fix -misched-regpressure=0 if subreg liveness enabled

Test is waiting on fixing several more crashes in the AMDGPU scheduler
implementation with this.

llvm-svn: 362174

Make ConnectionFileDescription work with all sockets

Summary:
My main goal here is to make lldb-server work with Android Studio.

This is currently not the case because lldb-server is started in platform mode listening on a domain socket. When Android Studio connects to it lldb-server crashes because even though it's listening on a domain socket as soon as it gets a connection it asserts that it's a TCP connection, which will obviously fails for any non-tcp connection.

To do this I came up with a new method called GetConnectURI() in Socket that returns the URI needed to connect to the connected portion of the socket.

Reviewers: labath, clayborg, xiaobai

Reviewed By: labath

Subscribers: mgorny, jfb, lldb-commits

Tags: #lldb

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

llvm-svn: 362173

Refactor OpenMP stack management.

Instead of duplicating access to the directive stack throughout
SemaOpenMP.cpp, consolidate it to a few methods and call those
everywhere else. In passing, simplify adjacent code where possible.

No functionality change intended.

llvm-svn: 362172

Fix "fallthrough annotation in unreachable code" warning.

llvm-svn: 362171

[X86] Remove code that unnecessarily sets EXTLOAD with src type of v2f32/v4f32/v8f32 as Legal for SSE2/AVX/AVX512 respectively. NFC

The LoadExt table defaults to all combinations being Legal. For
vector types, only src VTs with an i1 element type were ever changed.
So we don't need to mark them legal manually.

llvm-svn: 362170

Support codesigning bundles and forcing

Summary:
Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This results in an invalid bundle code signature because the signature only applies to the binaries not the resources.

This patch adds two new options to `llvm_codesign` to enable re-signing the library and XPC service as bundles.

The `BUNDLE_PATH` option allow specifying an explicit path to codesign, which enables signing bundles which aren't generated using CMake's `FRAMEWORK` or `BUNDLE` target properties.

The `FORCE` option allows re-signing binaries that have already been signed. This is required for how clangd exposes the clangd library and tools as both XPC and non-XPC services using the same binary.

Reviewers: jkorous, bogner

Reviewed By: bogner

Subscribers: mgorny, ilya-biryukov, dexonsmith, arphaman, kadircet, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 362169

Fix test to add missing '|' to regex.

llvm-svn: 362168

Update the tests in r362121 / r362141 to allow for Windows-specific error
messages: "Is a directory" instead of "is a directory"

This should resolve the errors being reported on clang-x64-windows-msvc.

llvm-svn: 362167

Add enums as global variables in the IR metadata.

Summary:
Keeps track of the enums that were used by saving them as DIGlobalVariables,
since CodeView emits debug info for global constants.

Reviewers: rnk

Subscribers: aprantl, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 362166

[Remarks] Fix usage of enum class

Breaks the build on some compilers:

http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/9720/steps/build%20stage%201/logs/stdio

llvm-svn: 362165

[Target] Generalize language-specific behavior in ThreadPlanStepThrough

Summary:
When creating a ThreadPlan to step through a trampoline, we ask the
ObjC language runtime and the CPP language runtime to come up with such a thread
plan if the dynamic loader fails to give us one. I don't see why this behavior
can't be language agnostic.

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

llvm-svn: 362164

Attempt to fix test failure for armv8.

Looks like armv8 can't handle a thousand threads, which GWP-ASan
requests when running a synchronised mutex test. Limiting this to 100 to
attempt to fix the build issue.

llvm-svn: 362163

[WebAssembly] Improve feature validation error messages

Summary:
Add the names of the input files responsible for each error to the
messages.

Reviewers: sbc100, azakai

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 362162

[Remarks][NFC] Move the serialization to lib/Remarks

Separate the remark serialization to YAML from the LLVM Diagnostics.

This adds a new serialization abstraction: remarks::Serializer. It's
completely independent from lib/IR and it provides an easy way to
replace YAML by providing a new remarks::Serializer.

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

llvm-svn: 362160

[NFC][ARM] Add a test that potentially causes endless combine loop with D62266

llvm-svn: 362159

[MIR-Canon] Fixing case where MachineFunction is empty.

In cases where the machine function is empty: bail on the RPO traversal.

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

llvm-svn: 362158

Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.

As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was
possible to get the constexpr version of __builtin_*_overflow to give
the wrong answer.

This was because when extending the operands to fit the largest type (so
that the math could be done), the decision on whether to sign/zero
extend the operands was based on the result signedness, not on the
operands signedness.

In the reported case, (unsigned char)255 - (int)100 needed
to have each extended to the int in order to do the math.  However, when
extending the first operand to 'int', we incorrectly sign extended it
instead of zero extending.  Thus, the result didnt fit back into the
unsigned char.

The fix for this was simply to choose zero/sign extension based on the
sign of the operand itself.

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

llvm-svn: 362157

[DAGCombine] Limit 'hoist add/sub binop w/ constant op' to non-opaque consts

I don't have a test case for these, but there is a test case for D62266
where, even after all the constant-folding patches, we still end up
with endless combine loop. Which makes sense, since we don't constant
fold for opaque constants.

llvm-svn: 362156

[pstl] Use OpenMP pragmas with Clang, which supports them

Most importantly, Clang doesn't seem to support the non-OpenMP pragmas
that were being used previously.

llvm-svn: 362155

[Target] Generalize Process::IsPossibleDynamicValue

llvm-svn: 362154

[CVP] Add tests for non-overflowing saturating math; NFC

llvm-svn: 362153

[CVP] Generalize willNotOverflow(); NFC

Change argument from WithOverflowInst to BinaryOpIntrinsic, so this
function can also be used for saturating math intrinsics.

llvm-svn: 362152

[RuntimeDyld] Update reserveAllocationSpace to account for stub padding.

This should fix the buildbot failures caused by r362139.

llvm-svn: 362151

[InstCombine] Avoid use after free in DenseMap, when built with GCC

Previously, this used a statement like this:
    Map[A] = Map[B];

This is equivalent to the following:
    const auto &Src = Map[B];
    auto &Dest = Map[A];
    Dest = Src;

The second statement, "auto &Dest = Map[A];" can insert a new
element into the DenseMap, which can potentially grow and reallocate
the DenseMap's internal storage, which will invalidate the existing
reference to the source. When doing the actual assignment,
the Src reference is dereferenced, accessing memory that was
freed when the DenseMap grew.

This issue hasn't shown up when LLVM was built with Clang, because
the right hand side ended up dereferenced before evaulating the
left hand side. (If the value type is a larger data type, Clang doesn't
do this but behaves like GCC.)

With GCC, a cast to Value* isn't enough to make it dereference the
right hand side reference before invoking operator[] (while that is
enough to make Clang/LLVM do the right thing for larger types), but
storing it in an intermediate variable in a separate statement works.

This fixes PR42065.

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

llvm-svn: 362150

Attempt to fix 'mutex.h' not found when building mutex_posix.

llvm-svn: 362149

[pstl] Remove various warnings in the pstl headers and tests

- unused parameter warnings
- don't use single-letter template parameter names, like we do in libc++
- sign-comparison warnings
- unused variables in the tests
- unused local typedefs in the tests
- the use of #include_next
- field reordering in the tests
- unused lambda captures

Note that the rationale for why the static_casts to unsigned are OK is
that last - first must always be non-negative, since [first, last) is
a valid range.

llvm-svn: 362148

[c++2a] Fix assertion failure if we would walk over more than one level
of derived-to-base conversion path when implicitly starting union
subobject lifetimes in constant evaluation.

llvm-svn: 362147

[DAGCombiner][X86][AArch64] (x - C) + y  ->  (x + y) - C  fold. Try 2

Summary:
Only vector tests are being affected here,
since subtraction by scalar constant is rewritten
as addition by negated constant.

No surprising test changes.

https://rise4fun.com/Alive/pbT

This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs.

Reviewers: RKSimon, craig.topper, spatel

Reviewed By: RKSimon

Subscribers: javed.absar, kristof.beyls, llvm-commits

Tags: #llvm

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

llvm-svn: 362146

[DAGCombine] (x - C) - y  ->  (x - y) - C  fold. Try 3

Summary:
Again only vectors affected. Frustrating. Let me take a look into that..

https://rise4fun.com/Alive/AAq

This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.

Reviewers: RKSimon, craig.topper, spatel

Reviewed By: RKSimon

Subscribers: javed.absar, JDevlieghere, llvm-commits

Tags: #llvm

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

llvm-svn: 362145

[DAGCombine][X86][AArch64][AMDGPU] (x - y) + -1  ->  add (xor y, -1), x  fold. Try 3

Summary:
This prevents regressions in next patch,
and somewhat recovers from the regression to AMDGPU test in D62223.

It is indeed not great that we leave vector decrement,
don't transform it into vector add all-ones..

https://rise4fun.com/Alive/ZRl

This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.

Reviewers: RKSimon, craig.topper, spatel, arsenm

Reviewed By: RKSimon, arsenm

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits

Tags: #llvm

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

llvm-svn: 362144

[DAGCombiner][X86][AArch64][SPARC][SystemZ] y - (x + C)  ->  (y - x) - C  fold. Try 3

Summary:
Direct sibling of D62223 patch.
While i don't have a direct motivational pattern for this,
it would seem to make sense to handle both patterns (or none),
for symmetry?

The aarch64 changes look neutral;
sparc and systemz look like improvement (one less instruction each);
x86 changes - 32bit case improves, 64bit case shows that LEA no longer
gets constructed, which may be because that whole test is `-mattr=+slow-lea,+slow-3ops-lea`

https://rise4fun.com/Alive/ffh

This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.

Reviewers: RKSimon, craig.topper, spatel, t.p.northover

Reviewed By: t.p.northover

Subscribers: t.p.northover, jyknight, javed.absar, kristof.beyls, fedor.sergeev, jrtc27, llvm-commits

Tags: #llvm

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

llvm-svn: 362143

[DAGCombiner][X86][AArch64][AMDGPU] (x + C) - y  ->  (x - y) + C  fold. Try 3

Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.

AArch64 test changes all look good (`neg` created), or neutral.

X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).

I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.

I'm unable to interpret AMDGPU change, looks neutral-ish?

This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].

https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)

This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.

Reviewers: craig.topper, RKSimon, spatel, arsenm

Reviewed By: RKSimon

Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits

Tags: #llvm

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

llvm-svn: 362142

Write new tests for r362121

Summary:
The tests for r362121 ran dsymutil against a test binary every time.
This caused problems on lld-x86_64-ubuntu-fast as dsymutil required
a lipo tool be available to process those binaries.

This change rewrites the new test cases in macho-disassemble-g-dsym
to use bespoke test binaries (exe and dwarf) simplifying the test's
runtime dependencies.

The changes to tools/llvm-objdump/MachODump.cpp are unchanged from
r362121

Reviewers: pete, lhames, JDevlieghere

Reviewed By: pete

Subscribers: smeenai, aprantl, rupprecht, llvm-commits

Tags: #llvm

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

llvm-svn: 362141

Mark test as requiring an ARM target.

llvm-svn: 362140

[RuntimeDyld] Apply padding and alignment bumps to all sections with stubs, and
increase the MachO/x86-64 stub alignment to 8.

Stub alignment should be guaranteed for any section containing RuntimeDyld
stubs/GOT-entries. To do this we should pad and align all sections containing
stubs, not just code sections.

This commit also bumps the MachO/x86-64 stub alignment to 8, so that GOT entries
will be aligned.

llvm-svn: 362139

[GWP-ASan] Mutex implementation [2].

Summary:
See D60593 for further information.
This patch pulls out the mutex implementation and the required definitions file.

We implement our own mutex for GWP-ASan currently, because:

1. We must be compatible with the sum of the most restrictive elements of the supporting allocator's build system. Current targets for GWP-ASan include Scudo (on Linux and Fuchsia), and bionic (on Android).
2. Scudo specifies `-nostdlib++ -nonodefaultlibs`, meaning we can't use `std::mutex` or `mtx_t`.
3. We can't use `sanitizer_common`'s mutex, as the supporting allocators cannot afford the extra maintenance (Android, Fuchsia) and code size (Fuchsia) overheads that this would incur.

In future, we would like to implement a shared base mutex for GWP-ASan, Scudo and sanitizer_common. This will likely happen when both GWP-ASan and Scudo standalone are not in the development phase, at which point they will have stable requirements.

Reviewers: vlad.tsyrklevich, morehouse, jfb

Reviewed By: morehouse

Subscribers: dexonsmith, srhines, cfe-commits, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, vitalybuka, eugenis

Tags: #sanitizers, #llvm, #clang

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

llvm-svn: 362138

[NFC][InstCombine] Add unary FNeg tests to fmul.ll

llvm-svn: 362137

AMDGPU/GlobalISel: Add wave scratch offset argument

Avoids crashing in PEI in a future change.

llvm-svn: 362136

[DAGCombine] ((c1-A)-c2) -> ((c1-c2)-A)  constant-fold

Summary: https://rise4fun.com/Alive/B0A

Reviewers: t.p.northover, RKSimon, spatel, craig.topper

Reviewed By: RKSimon

Subscribers: javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 362135

[DAGCombine] (A-C1)-C2 -> A-(C1+C2) constant-fold

Summary: https://rise4fun.com/Alive/Mb1M

Reviewers: RKSimon, craig.topper, spatel, t.p.northover

Reviewed By: t.p.northover

Subscribers: t.p.northover, javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 362134

[DAGCombine] (A+C1)-C2 -> A+(C1-C2) constant-fold

Summary:
Direct sibling of D62662, the root cause of the endless combine loop in D62257

https://rise4fun.com/Alive/d3W

Reviewers: RKSimon, craig.topper, spatel, t.p.northover

Reviewed By: t.p.northover

Subscribers: t.p.northover, javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 362133

[DAGCombine] Use FoldConstantArithmetic() to perform C2-(A+C1) -> (C2-C1)-A fold

Summary:
No tests change, and i'm not sure how to test this, but it's better safe than sorry.

Reviewers: spatel, RKSimon, craig.topper, t.p.northover

Reviewed By: craig.topper

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 362132

[DAGCombine] ((A-c1)+c2) -> (A+(c2-c1))  constant-fold

Summary:
This was the root cause of the endless combine loop in D62257

https://rise4fun.com/Alive/d3W

Reviewers: RKSimon, spatel, craig.topper, t.p.northover

Reviewed By: t.p.northover

Subscribers: t.p.northover, javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 362131

[DAGCombine] Use FoldConstantArithmetic() to perform ((c1-A)+c2) -> (c1+c2)-A fold

Summary: No tests change, and i'm not sure how to test this, but it's better safe than sorry.

Reviewers: spatel, RKSimon, craig.topper, t.p.northover

Reviewed By: craig.topper

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 362130

Reapply: LLVM IR: update Clang tests for byval being a typed attribute.

Since byval is now a typed attribute it gets sorted slightly differently by
LLVM when the order of attributes is being canonicalized. This updates the few
Clang tests that depend on the old order.

Clang patch is unchanged.

llvm-svn: 362129

Reapply: IR: add optional type to 'byval' function parameters

When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack. This adds
a (for now) optional extra type parameter.

If present, the type must match the pointee type of the argument.

The original commit did not remap byval types when linking modules, which broke
LTO. This version fixes that.

Note to front-end maintainers: if this causes test failures, it's probably
because the "byval" attribute is printed after attributes without any parameter
after this change.

llvm-svn: 362128

[AMDGPU] Added target-specific attribute amdgpu-max-memory-clause

With LLPC, previous investigation has suggested that si-scheduler
interacts badly with SiFormMemoryClauses on an XNACK target in some
games.

That needs further investigation in the future. In the meantime, this
commit adds a target-specific attribute to allow us to disable
SIFormMemoryClauses by setting it to 1 on a per-function basis for LLPC
to use.

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

Change-Id: Ia0ca12ce79093cbbe86caded723ffb13384ede92
llvm-svn: 362127

[LV] Remove the redundant using LoopVectorizationPlanner:VPlanPtr

VPlan.h already contains the declaration of VPlanPtr type alias:

using VPlanPtr = std::unique_ptr<VPlan>;

The LoopVectorizationPlanner class also contains the same declaration
of VPlanPtr and therefore LoopVectorize requires a long wording when
its methods return VPlanPtr:

    LoopVectorizationPlanner::VPlanPtr
    LoopVectorizationPlanner::buildVPlanWithVPRecipes(...)

but LoopVectorize.cpp includes VPlan.h (via LoopVectorizationPlanner.h)
and can use VPlanPtr from that header.

Patch by Pavel Samolysov.

Reviewers: hsaito, rengolin, fhahn

Reviewed By: fhahn

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

llvm-svn: 362126

Fix OMP_TARGET_OFFLOAD parsing

Current parsing allows trailing string after the permitted value,
MANDATORY|DISABLED|DEFAULT -- e.g., "mandatorynot" is also recognized
as "MANDATORY". Such cases should be recognized as incorrect/unknown
value.

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

llvm-svn: 362125

[LoopVectorize] Add FNeg instruction support

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

llvm-svn: 362124

Reverting change r362121 due to lld-x86_64-ubuntu-fast test failures

llvm-svn: 362123

[MIR-Canon] Add support for rewriting VRegs that are typed but don't have an RC.

There were crashes (addrspace-memoperands.mir was only one of them) in MIR that
had operands that came from before register classes were set. With these
operands, creating a replacement vreg (for MIR-Canon's renaming) needs to use
the vreg type rather than the RegisterClass which is not present.

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

llvm-svn: 362122

Support Universal dSYM files in llvm-objdump

Summary:
Commonly programmers use llvm-objdump to disassemble Mach-O target
binaries with Mach-O dSYMS. While llvm-objdump allows programmers to
disassemble Universal binaries, it previously did not recognize
Universal dSYM files. This change updates llvm-objdump to support
passing in Universal files via the -dsym option. Now, when
disassembling a Mach-O file either as a stand alone file or as an entry
in a Universal binariy, llvm-objdump will search through a Universal
dSYM for a Mach-O matching the architecture flag of the file being
disassembled.

Reviewers: pete, lhames

Reviewed By: pete

Subscribers: rupprecht, llvm-commits

Tags: #llvm

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

llvm-svn: 362121

[NFC] Fix SmallVector::append comments

Fix the copy-pasted comment.
Remove low-value comments.

llvm-svn: 362120

Add Attribute NoThrow as an Exception Specifier Type

In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became
clear that the current mechanism of hacking through checks for the
exception specification of a function gets confused really quickly when
there are alternate exception specifiers.

This patch introcues EST_NoThrow, which is the equivilent of
EST_noexcept when caused by EST_noThrow. The existing implementation is
left in place to cover functions with no FunctionProtoType.

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

llvm-svn: 362119

Correct error in revert of r362112.

Differential Revision: http://reviews.llvm.org/D62546

llvm-svn: 362118

Revert r362112, it broke the bots with the message "Unsupported vector argument or return type"

Differential Revision: http://reviews.llvm.org/D62546

llvm-svn: 362117

Code and comment cleanups [NFC]

Changes:
- update comments to detail the info can come from .debug_info or .debug_types
- Rename "debug_info_data" to "data" now that we can get data from .debug_info or .debug_types.
- Also call DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) instead of manually grabbing abbreviation.

llvm-svn: 362116

[libcxx] Add regex test cases from PR40904

llvm-svn: 362115

[NFC][Codegen] Potential add/sub constant folding: fixup non-splat tests

llvm-svn: 362114

[Docs] Modernize references to macOS

Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.

If a specific version is mentioned, this attempts to use the OS name at the time
of that version:

* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present

Reviewers: JDevlieghere

Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits

Tags: #clang, #lldb, #libc, #llvm

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

llvm-svn: 362113

[FPEnv] Added a special UnrollVectorOp method to deal with the chain on StrictFP opcodes

This change creates UnrollVectorOp_StrictFP. The purpose of this is to address a failure that consistently occurs when calling StrictFP functions on vectors whose number of elements is 3 + 2n on most platforms, such as PowerPC or SystemZ. The old UnrollVectorOp method does not expect that the vector that it will unroll will have a chain, so it has an assert that prevents it from running if this is the case. This new StrictFP version of the method deals with the chain while unrolling the vector. With this new function in place during vector widending, llc can run vector-constrained-fp-intrinsics.ll for SystemZ successfully.

Submitted by: Drew Wock <drew.wock@sas.com>
Reviewed by: Cameron McInally, Kevin P. Neal
Approved by: Cameron McInally
Differential Revision: http://reviews.llvm.org/D62546

llvm-svn: 362112

Add checks before pointer dereferencing

This change adds checks before dereferencing a pointer returned from a
function.

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

llvm-svn: 362111

[NFC][Codegen] Add better test coverage for potential add/sub constant folding

This adds hopefully-full test coverage for all the possible permutations:
First op is one of:
* x + c1
* x - c1
* c1 - x

Second op is one of:
* + c2
* - c2
* c2 -

And thus 3*3=9 patterns.
Some of them show missed constant-folds.

Without previous patch (the revert), these tests were causing endless
dagcombine loop. I really should have thought about this first :S

llvm-svn: 362110

[DAGCombine] Revert of recommit of "binop-with-const hoisting" patches

I was looking into an endless combine loop the uncommitted follow-up patch
was causing, and it appears even these patches can exibit such an
endless loop. The root cause is that we try to hoist one binop (add/sub) with
constant operand, and if we get two such binops both of which are
eligible for this hoisting, we get stuck.

Some cases may highlight missing constant-folds.

Reverts r361871,r361872,r361873,r361874.

llvm-svn: 362109

[ELF] Delete dead SHT_NOBITS->SHT_PROGBITS code after r358981

After D60131/r358981, we no longer create SHT_NOBITS sections that may
contain ByteCommand (BYTE, SHORT, LONG, QUAD).

llvm-svn: 362108

Remove length modifier when using assignment suppression in TimerTest

Summary:
This is useless and it's giving warnings in the build bots:
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/unittests/Utility/TimerTest.cpp:67:43: warning: use of assignment suppression and length modifier together in gnu_scanf format [-Wformat=]

Reviewers: xiaobai

Subscribers: krytarowski, lldb-commits

Tags: #lldb

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

llvm-svn: 362107

Revert "clang support gnu asm goto."

This reverts commit 954ec09aed4f2be04bb5f4e10dbb4ea8bd19ef9a.

Reverting due to test failures as requested by Jennifer Yu.

Conflicts:
clang/test/CodeGen/asm-goto.c

llvm-svn: 362106

Fix a regression in DWARF access speed caused by svn revision 356190

The issue was caused by the error checking code that was added. It was incorrectly adding an extra abbreviation when DWARFEnumState::Complete was received since it would push an extra abbreviation onto the list with the abbreviation code of zero. This cause m_idx_offset in each DWARFAbbreviationDeclarationSet to be set to UINT32_MAX. This valid indicates we must linearly search for attributes, not access them in O(1) time. This caused every DWARFDebugInfoEntry that would try to get its DWARFAbbreviationDeclaration from the CU's DWARFAbbreviationDeclarationSet to always linearly search the abbreviation set for a given abbreviation code. Easy to see why this would cause things to be slow.

This regression was caused by: https://reviews.llvm.org/D59370. I asked to ensure there was no regression is parsing or access speed, but that must not have been done. In my test with 40 DWARF files trying to set a breakpoint by function name and in a header file, I see a 8% speed improvement with this fix.

There was no regression in correctness, just very inefficient access.

Added full unit testing for DWARFAbbreviationDeclarationSet parsing to ensure this doesn't regress.

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

llvm-svn: 362105

[NFC][ARM][ParallelDSP] Refactor narrow sequence

Most of the code used for finding a 'narrow' sequence is not used,
so I've removed it and simplified the calls from the smlad matcher.

llvm-svn: 362104

Improve DWARF parsing and accessing by 1% to 2%

When LLDB first started we didn't have our mmap of the DWARF data done correctly and if the backing file would change we would get live changes as the file changed and it would cause problems. We now mmap correctly and do not run into these issues. There was legacy code in DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) that would always extract the abbrev index each time the function was called to verify that DWARF data hadn't changed and a warning was emitted if it did. We no longer need this and the code was removed. The other thing this function did when it parsed the abbrev index was give us the offset of the first attribute bytes by adding the LEB128 size to the offset. This required an extra parameter to DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) which is now removed. I added "lldb::offset_t DWARFDebugInfoEntry::GetFirstAttributeOffset() const" which calculates this when we need it and modified all sites that need the offset to call it.

Now that we aren't decoding and verifying the abbrev index, it speeds up DWARF access by 1% to 2%.

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

llvm-svn: 362103

[OpenCL] Fix OpenCL/SPIR version metadata in C++ mode.

C++ is derived from OpenCL v2.0 therefore set the versions
identically.

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

llvm-svn: 362102

[analyzer] print() JSONify chain: Fix possible build-bot breaks

Summary:
Printing constructing_objects could be non-deterministic as it is a map.

llvm-svn: 362101

Follow up of r362096

The new tests were failing, because I missed dependent patch D60697.
I have removed the failing cases for now, which I will restore once
D60697 is in.

llvm-svn: 362100

[ELF] De-template addUndefined() and addWrappedSymbols(). NFC

llvm-svn: 362099

[analyzer] print() JSONify chain: Fix build-bot breaks

Summary:
Printing out a map structure different in different environments so that
this patch generalize the test-case to check for the 'no stmt'-case
anywhere in the Store.

llvm-svn: 362098

[ARM] Change the MC names for VMAXNM/VMINNM

Now the NEON ones have a prefix "NEON_", and the VFP ones have a
prefix "VFP_". This is so that the regex in ARMScheduleA57.td can be
made to match both of _those_ classes of VMAXNM without also matching
the MVE ones that are going to be introduced soon. NFCI.

Patch by Simon Tatham.

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

llvm-svn: 362097

[ARM] Add CLI support for Armv8.1-M and MVE

Given the existing infrastructure in LLVM side for +fp and +fp.dp,
this is more or less trivial, needing only one tiny source change and
a couple of tests.

Patch by Simon Tatham.

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

llvm-svn: 362096

[ELF][test] Update znotext-plt-relocations.s to emit R_X86_64_PC32

This is a leftover from r325379.

The intention of this test was to check in a non-pic link, R_X86_64_PC32
to a STT_FUNC created a PLT. However, after the llvm-mc change in
r325569, this code path is no longer exercised. Use the r325379 trick to
keep testing R_X86_64_PC32.

llvm-svn: 362095

[ARM] LowerVECTOR_SHUFFLE - fix uninitialized variable warnings. NFCI.

llvm-svn: 362094

[NFC][Codegen] Add add+sub/sub+add constant-fold tests for from D62257

add+sub/sub+add when second operands are constants should be folded
into a single add, just like with add+add.

llvm-svn: 362093

[LoopIdiom] Basic OptimizationRemarkEmitter handling

Summary:
I'm adding ORE to memset/memcpy formation, with tests,
but mainly this is split off from D61144.

Reviewers: reames, anemet, thegameg, craig.topper

Reviewed By: thegameg

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 362092

[LoopIdiomRecognize][NFC] Sort includes

Split off from D61144

llvm-svn: 362091

[ARM] add target arch definitions for 8.1-M and MVE

This adds:
- LLVM subtarget features to make all the new instructions conditional on,
- CPU and FPU names for use on clang's command line, with default FPUs set
  so that "armv8.1-m.main+fp" and "armv8.1-m.main+fp.dp" will select the right
  FPU features,
- architecture extension names "mve" and "mve.fp",
- ABI build attribute support for v8.1-M (a new value for Tag_CPU_arch) and MVE
  (a new actual tag).

Patch mostly by Simon Tatham.

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

llvm-svn: 362090

[llvm-readobj] - Rewrite reloc-types.test to use YAML. NFCI.

This change rewrites and splits reloc-types.test
to use yaml2obj instead of precompiled binaries.
That allowed to remove 7 precompiled objects from the inputs.

I took the existent objects, used obj2yaml on them, simplified the result and
used yaml2obj in the test case with the result.

Notes:
* I converted, but did not remove relocs.obj.elf-i386, relocs.obj.elf-x86_64 or relocs.obj.elf-mips objects
because found they are used in other tests.
* I was unable to convert relocs.obj.elf-ppc64, because obj2yaml hangs on this file for me.
* I was unable to convert relocs.obj.macho-arm, relocs.obj.macho-i386 and relocs.obj.macho-x86_64
because the output produced by obj2yaml does not seem to be correct.
* Because of the above I did not remove the script for creating all
of those objects: test\tools\llvm-readobj\Inputs\relocs.py

Differential revision: https://reviews.llvm.org/D62594

llvm-svn: 362089

[ARM] Introduce separate features for FP registers

The MVE extension in Arm v8.1-M permits the use of some move, load and
store isntructions which access the FP registers, even if there's no
actual FP support in the processor (in particular, if you have the
integer-only version of MVE).

Therefore, we need separate subtarget features to condition those
instructions on, which are implied by both FP and MVE but are not part
of either.

Patch mostly by Simon Tatham.

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

llvm-svn: 362088

[OpenCL] Support logical vector operators in C++ mode

Support logical operators on vectors in C++ for OpenCL mode, to
preserve backwards compatibility with OpenCL C.

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

llvm-svn: 362087

DWARFASTParserClang: Delete dead code

This removes places where DW_AT_decl_file/line/column was being parsed,
but not used.

llvm-svn: 362086

Fix Wdocumentation warning. NFCI.

llvm-svn: 362085

[llvm-readobj] - An attemp to fix BB.

BB failed:
http://lab.llvm.org:8011/builders/clang-armv7-linux-build-cache/builds/15062/steps/build%20stage%201/logs/stdio

Error was:
/home/buildslave/buildslave/clang-armv7-linux-build-cache/llvm/tools/llvm-readobj/ELFDumper.cpp:3540:7:
error: non-constant-expression cannot be narrowed from type 'llvm::support::detail::packed_endian_specific_integral<unsigned long long,
llvm::support::endianness::little, 1>::value_type' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
      StrTabSec->sh_size};

llvm-svn: 362084

[CostModel][X86] Add bool vector and/or/xor cost tests

llvm-svn: 362083

[llvm-readobj/llvm-readelf] - Implement GNU style dumper of the SHT_GNU_verdef section.

It was not implemented yet, we had only LLVM style dumper implemented.
Section description is here: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/symversion.html

Differential revision: https://reviews.llvm.org/D62520

llvm-svn: 362082

[X86][SSE] Improve bool vector extload (PR26091)

We already have good codegen for (vXiY *ext(vXi1 bitcast(iX))) cases, this patch uses it for loads of vXi1 types as well - changing the load into a iX integer load, and bitcasting so that combineToExtendBoolVectorInReg can then use it.

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

llvm-svn: 362081

[llvm-readobj/llvm-readelf] - Implement GNU style dumper of the SHT_GNU_verneed section.

It was not implemented yet, we had only LLVM style dumper implemented.
Section description is here: https://refspecs.linuxfoundation.org/LSB_2.0.1/LSB-Core/LSB-Core/symverrqmts.html

Differential revision: https://reviews.llvm.org/D62516

llvm-svn: 362080