Update the pr_datasz of .note.gnu.property section.
Patch by Xiang Zhang.

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

llvm-svn: 350436

[BDCE] Remove dead uses of arguments

In addition to finding dead uses of instructions, also find dead uses
of function arguments, and replace them with zero as well.

I'm changing the way the known bits are computed here to remove the
coupling between the transfer function and the algorithm. It previously
relied on the first op being visited first and computing known bits --
unless the first op is not an instruction, in which case they're computed
on the second op. I could have adjusted this to check for "instruction
or argument", but I think it's better to avoid the repeated calculation
with an explicit flag.

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

llvm-svn: 350435

[AArch64] Adjust the cost model for Exynos M3

Improve the modeling of ASIMD loads and stores.

llvm-svn: 350434

Fix default-function-attr.c so that it works on Windows.

llvm-svn: 350433

[X86] Add INSERT_SUBVECTOR to ComputeNumSignBits

This adds support for calculating sign bits of insert_subvector. I based it on the computeKnownBits.

My motivating case is propagating sign bits information across basic blocks on AVX targets where concatenating using insert_subvector is common.

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

llvm-svn: 350432

[OPENMP][NVPTX]General formatting/code improvement, NFC.

Summary: Formatting.

Reviewers: gtbercea, grokos, kkwli0

Subscribers: guansong, openmp-commits, caomhin

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

llvm-svn: 350431

[x86] add tests for potential horizontal vector ops; NFC

These are modified versions of the FP tests from rL349923.

llvm-svn: 350430

hwasan: Implement lazy thread initialization for the interceptor ABI.

The problem is similar to D55986 but for threads: a process with the
interceptor hwasan library loaded might have some threads started by
instrumented libraries and some by uninstrumented libraries, and we
need to be able to run instrumented code on the latter.

The solution is to perform per-thread initialization lazily. If a
function needs to access shadow memory or add itself to the per-thread
ring buffer its prologue checks to see whether the value in the
sanitizer TLS slot is null, and if so it calls __hwasan_thread_enter
and reloads from the TLS slot. The runtime does the same thing if it
needs to access this data structure.

This change means that the code generator needs to know whether we
are targeting the interceptor runtime, since we don't want to pay
the cost of lazy initialization when targeting a platform with native
hwasan support. A flag -fsanitize-hwaddress-abi={interceptor,platform}
has been introduced for selecting the runtime ABI to target. The
default ABI is set to interceptor since it's assumed that it will
be more common that users will be compiling application code than
platform code.

Because we can no longer assume that the TLS slot is initialized,
the pthread_create interceptor is no longer necessary, so it has
been removed.

Ideally, lazy initialization should only cost one instruction in the
hot path, but at present the call may cause us to spill arguments
to the stack, which means more instructions in the hot path (or
theoretically in the cold path if the spills are moved with shrink
wrapping). With an appropriately chosen calling convention for
the per-thread initialization function (TODO) the hot path should
always need just one instruction and the cold path should need two
instructions with no spilling required.

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

llvm-svn: 350429

[Scalar] Simplify comparison operators and add coverage.

llvm-svn: 350428

hwasan: Use system allocator to realloc and free untagged pointers in interceptor mode.

The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value. This behaviour is activated by the
DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to
the linker, which is what we already do to link the hwasan runtime.

What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.

We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.

One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.

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

llvm-svn: 350427

[HIP][DRIVER][OFFLOAD] Do not unbundle unsupported file types

The offload bundler action should not unbundle the input file types that does not match the action type. This fixes an issue where .so files are unbundled when the action type is object files.

Reviewers: yaxunl

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

llvm-svn: 350426

[HIP][DRIVER][OFFLOAD] Do not unbundle unsupported file types

The offload bundler action should not unbundle the input file types that does not match the action type. This fixes an issue where .so files are unbundled when the action type is object files.

llvm-svn: 350425

[ThinLTO] Clang changes to utilize new pass to handle chains of aliases

Summary:
As with NameAnonGlobals, invoke the new CanonicalizeAliases via clang
when using the new PM.

Depends on D54507.

Reviewers: pcc, davidxl

Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, cfe-commits

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

llvm-svn: 350424

[ThinLTO] Handle chains of aliases

At -O0, globalopt is not run during the compile step, and we can have a
chain of an alias having an immediate aliasee of another alias. The
summaries are constructed assuming aliases in a canonical form
(flattened chains), and as a result only the base object but no
intermediate aliases were preserved.

Fix by adding a pass that canonicalize aliases, which ensures each
alias is a direct alias of the base object.

Reviewers: pcc, davidxl

Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits

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

llvm-svn: 350423

[ObjCARC] Add an new attribute, objc_externally_retained

This attribute, called "objc_externally_retained", exposes clang's
notion of pseudo-__strong variables in ARC. Pseudo-strong variables
"borrow" their initializer, meaning that they don't retain/release
it, instead assuming that someone else is keeping their value alive.

If a function is annotated with this attribute, implicitly strong
parameters of that function aren't implicitly retained/released in
the function body, and are implicitly const. This is useful to expose
for performance reasons, most functions don't need the extra safety
of the retain/release, so programmers can opt out as needed.

This attribute can also apply to declarations of local variables,
with similar effect.

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

llvm-svn: 350422

[x86] lower extracted fadd/fsub to horizontal vector math; 2nd try

The 1st try for this was at rL350369, but it caused IR-level diffs because
our cost models differentiate custom vs. legal/promote lowering. So that was
reverted at rL350373. The cost models were fixed independently at rL350403,
so this is effectively the same patch as last time.

Original commit message:
This would show up if we fix horizontal reductions to narrow as they go along,
but it's an improvement for size and/or Jaguar (fast-hops) independent of that.

We need to do this late to not interfere with other pattern matching of larger
horizontal sequences.

We can extend this to integer ops in a follow-up patch.

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

llvm-svn: 350421

[CodeExtractor] Do not extract unsafe lifetime markers

Lifetime markers which reference inputs to the extraction region are not
safe to extract. Example ('rhs' will be extracted):

```
               entry:
              +------------+
              | x = alloca |
              | y = alloca |
              +------------+
             /              \
   lhs:                      rhs:
  +-------------------+     +-------------------+
  | lifetime_start(x) |     | lifetime_start(x) |
  | use(x)            |     | lifetime_start(y) |
  | lifetime_end(x)   |     | use(x, y)         |
  | lifetime_start(y) |     | lifetime_end(y)   |
  | use(y)            |     | lifetime_end(x)   |
  | lifetime_end(y)   |     +-------------------+
  +-------------------+
```

Prior to extraction, the stack coloring pass sees that the slots for 'x'
and 'y' are in-use at the same time. After extraction, the coloring pass
infers that 'x' and 'y' are *not* in-use concurrently, because markers
from 'rhs' are no longer available to help decide otherwise.

This leads to a miscompile, because the stack slots actually are in-use
concurrently in the extracted function.

Fix this by moving lifetime start/end markers for memory regions defined
in the calling function around the call to the extracted function.

Fixes llvm.org/PR39671 (rdar://45939472).

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

llvm-svn: 350420

[InstCombine] reduce raw IR narrowing rotate patterns to funnel shift

Similar to rL350199 - there are no known analysis/codegen holes for
funnel shift intrinsics now, so we can canonicalize the 6+ regular
instructions to funnel shift to improve vectorization, inlining,
unrolling, etc.

llvm-svn: 350419

[gn build] Merge r350351

llvm-svn: 350418

[gn build] Commit change that should have been in r350410.

llvm-svn: 350416

[OPENMP][NVPTX]Use new functions from the runtime library.

Updated codegen to use the new functions from the runtime library.

llvm-svn: 350415

Add two new pragmas for controlling software pipelining optimizations.

This patch adds #pragma clang loop pipeline and #pragma clang loop pipeline_initiation_interval for debugging or reducing compile time purposes. It is possible to disable SWP for concrete loops to save compilation time or to find bugs by not doing SWP to certain loops. It is possible to set value of initiation interval to concrete number to save compilation time by not doing extra pipeliner passes or to check created schedule for specific initiation interval.

Patch by Alexey Lapshin.

llvm-svn: 350414

[gn build] Add even more build files for LLVM unittests

Another random assortment of easy build files.

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

llvm-svn: 350413

[gn build] Add more build files for LLVM unittests

A fairly random assortment of build files that are easy.

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

llvm-svn: 350412

[gn build] Start adding build files for LLVM unittests

Adds build files for //llvm/unittest/[A-D].

Also teach sync_source_lists_from_cmake.py to not complain about missing
BUILD.gn files for CMakeLists.txt files that just call add_subdirectory()
without calling add_.+_unittest, like e.g.
llvm/unittests/Target/CMakeLists.txt.

(Omits CodeGen/GlobalISel and DebugInfo/PDB because their build files are somewhat interesting, and this patch is already on the larger side.)

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

llvm-svn: 350411

[gn build] Add check-llvm target and make it work

With this, check-llvm runs and passes all of clang's lit tests. It doesn't run
any of its unit tests yet.

This is the only change in the GN build patch series that needs a change to a
file outside of llvm/utils/gn: llvm/test/tools/llvm-config/booleans.test checks
the result of llvm-config --build-system for some reason, so I'm updating the
test to accept "gn" as valid output in addition to "cmake". (The alternative
would be to let the gn build self-identify as cmake, which seems worse.)

Like with check-clang and check-lld, running just ninja -C out/gn will build
all prerequisites needed to run tests, but it won't run the tests (so that the
build becomes clean after one build). Running ninja -C out/gn check-llvm will
build prerequisites if needed and run the tests. The check-llvm target never
becomes clean and runs tests every time.

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

llvm-svn: 350410

[gn build] Add build file for libLTO.dylib

Not used by anything yet, but will be needed to make check-llvm run ld64's libLTO plugin tests.

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

llvm-svn: 350409

[LICM] Adjust how moving the re-hoist point works

In some cases the order that we hoist instructions in means that when rehoisting
(which uses the same order as hoisting) we can rehoist to a block A, then a
block B, then block A again. This currently causes an assertion failure as it
expects that when changing the hoist point it only ever moves to a block that
dominates the hoist point being moved from.

Fix this by moving the re-hoist point when it doesn't dominate the dominator of
hoisted instruction, or in other words when it wouldn't dominate the uses of
the instruction being rehoisted.

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

llvm-svn: 350408

[gn build] Add build files for llvm/lib/{LineEditor,Testing/Support,TextAPI}

Nothing pulls them in yet, but they will be needed for check-llvm.

LineEditor depends on libedit, so create a gn/build/lib for it, following the
usual pattern.

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

llvm-svn: 350407

Undo r350355 "[X86] Remove terrible DX Register parsing hack in parse operand. NFCI."

Add missing test case and update comments.

llvm-svn: 350406

[OPENMP][NVPTX]Improve performance + reduce number of used registers.

Summary:
Reduced number of the used register + improved performance propagating
the information about current execution/data sharing mode directly from
the compiler, where it is possible.
In some cases, it requires new/reworked interfaces of the runtime
external functions. Old functions are marked as deprecated.

Reviewers: grokos, gtbercea, kkwli0

Subscribers: guansong, jfb, openmp-commits, caomhin

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

llvm-svn: 350405

Refactor the way we handle diagnosing unused expression results.

Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement.

This patch fixes PR39837.

llvm-svn: 350404

[CostModel][X86] Fix SSE1 FADD/FSUB costs

Noticed in D56011 - handle the case that scalar fp ops are quicker on P3 than P4

Add the other costs so that we're not relying on the default "is legal/custom" cost logic.

llvm-svn: 350403

Revert patches 348835 and 348571 because they're
causing code size performance regressions.

llvm-svn: 350402

[CostModel][X86] Add SSE1 fp cost tests

llvm-svn: 350401

Fix typo: "with he MODULE" -> "with the MODULE"

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

llvm-svn: 350400

[X86] Add VPSLLI/VPSRLI ((X >>u C1) << C2) SimplifyDemandedBits combine

Repeat of the generic SimplifyDemandedBits shift combine

llvm-svn: 350399

Prevent unreachable when checking invalid multiversion decls.

CPUSpecifc/CPUDispatch call resolution assumed that all declarations
that would be passed are valid, however this was an invalid assumption.
This patch deals with those situations by making the valid version take
priority.  Note that the checked ordering is arbitrary, since both are
replaced by calls to the resolver later.

Change-Id: I7ff2ec88c55a721d51bc1f39ea1a1fe242b4e45f
llvm-svn: 350398

[MCA] Improved handling of in-order issue/dispatch resources.

Added field 'MustIssueImmediately' to the instruction descriptor of instructions
that only consume in-order issue/dispatch processor resources.
This speeds up queries from the hardware Scheduler, and gives an average ~5%
speedup on a release build.

No functional change intended.

llvm-svn: 350397

[X86] Split immediate shifts tests. NFCI.

A future patch will combine logical shifts more aggressively.

llvm-svn: 350396

[ValueTracking] Fix a misuse of APInt in GetPointerBaseWithConstantOffset

GetPointerBaseWithConstantOffset include this code, where ByteOffset
and GEPOffset are both of type llvm::APInt :

  ByteOffset += GEPOffset.getSExtValue();

The problem with this line is that getSExtValue() returns an int64_t, but
the += matches an overload for uint64_t. The problem is that the resulting
APInt is no longer considered to be signed. That in turn causes assertion
failures later on if the relevant pointer type is > 64 bits in width and
the GEPOffset was negative.

Changing it to

  ByteOffset += GEPOffset.sextOrTrunc(ByteOffset.getBitWidth());

resolves the issue and explicitly performs the sign-extending
or truncation. Additionally, instead of asserting later if the result
is > 64 bits, it breaks out of the loop in that case.

See also
 https://reviews.llvm.org/D24729
 https://reviews.llvm.org/D24772

This commit must be merged after D38662 in order for the test to pass.

Patch by Michael Ferguson <mpfergu@gmail.com>.

Reviewers: reames, sanjoy, hfinkel

Reviewed By: hfinkel

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

llvm-svn: 350395

[gn build] Make write_cmake_config.py check that each key passed is unique

I got that wrong once while locally while working on check-llvm.

Reviewed as part of https://reviews.llvm.org/D56195

llvm-svn: 350394

[CMake] Python bindings generation polishing

Summary:
Simplify SWIG invocation and handling of generated files.

The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory.

Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai

Reviewed By: aprantl

Subscribers: mgorny, lldb-commits, #lldb

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

llvm-svn: 350393

[CMake] Revised RPATH handling

Summary:
If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.

* In the build-tree, tools use the absolute path to the framework's actual output location.
* In the install-tree, tools get a list of RPATHs to look for the framework when deployed.

`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree.
If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree).
If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree.
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks".

Reviewers: xiaobai, JDevlieghere, aprantl, clayborg

Reviewed By: JDevlieghere

Subscribers: ki.stfu, mgorny, lldb-commits, #lldb

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

llvm-svn: 350392

[CMake] Revised LLDB.framework builds

Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.

Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)

Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle

Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath

Reviewed By: aprantl

Subscribers: friss, mgorny, lldb-commits, #lldb

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

llvm-svn: 350391

[CMake] Move debugserver options to separate debugserverConfig.cmake

Summary:
One place for debugserver options, analog to LLDBConfig for LLDB options (see D55317). It was discussed in earlier reviews already, e.g. D55013.

Reviewers: JDevlieghere, aprantl, xiaobai

Reviewed By: aprantl, xiaobai

Subscribers: mgorny, lldb-commits, #lldb

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

llvm-svn: 350390

[CMake] Aggregate options for LLDB in LLDBConfig.cmake

Summary: In preparation for LLDB.framework changes, collect options for LLDB in LLDBConfig.cmake (used for both, standalone and in-tree builds of LLDB).

Reviewers: JDevlieghere, aprantl, xiaobai

Reviewed By: aprantl

Subscribers: srhines, mgorny, lldb-commits, #lldb

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

llvm-svn: 350389

[CMake] Streamline code signing for debugserver #2

Summary:
Major fixes after D54476 (use Diff1 as base for comparison to see only recent changes):
* In standalone builds target directory for debugserver must be LLDB's bin, not LLVM's bin
* Default identity for code signing must not force-override LLVM_CODESIGNING_IDENTITY globally

We have a lot of cases, make them explicit:

* ID used for code signing (debugserver and in tests):
** `LLDB_CODESIGN_IDENTITY` if set explicitly, or otherwise
** `LLVM_CODESIGNING_IDENTITY` if set explicitly, or otherwise
** `lldb_codesign` as the default

* On Darwin we have a debugserver target that:

* On other systems, the debugserver target is not defined, which is equivalent to **[3A]**

Common configurations on Darwin:
* **[1A]** `cmake -GNinja ../llvm` builds debugserver from source and signs with `lldb_codesign`, no code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[1A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_CODESIGN_IDENTITY=lldb_codesign ../llvm` builds debugserver from source and signs with `lldb_codesign`, ad-hoc code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[2A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_USE_SYSTEM_DEBUGSERVER=ON ../llvm` copies debugserver from system, ad-hoc code signing for other binaries (prints status: //Copy system debugserver from: /path/to/system/debugserver//)
* **[2B]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- ../llvm` same, but prints additional warning: //Cannot code sign debugserver with identity '-'. Will fall back to system's debugserver. Pass -DLLDB_CODESIGN_IDENTITY=lldb_codesign to override the LLVM value for debugserver.//
* **[3A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_NO_DEBUGSERVER=ON ../llvm` debugserver not available (prints status: //lldb debugserver will not be available)//

Reviewers: JDevlieghere, beanz, davide, vsk, aprantl, labath

Reviewed By: JDevlieghere, labath

Subscribers: mgorny, #lldb, lldb-commits

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

llvm-svn: 350388

[MCA] Store extra information about processor resources in the ResourceManager.

Method ResourceManager::use() is responsible for updating the internal state of
used processor resources, as well as notifying resource groups that contain used
resources.

Before this patch, method 'use()' didn't know how to quickly obtain the set of
groups that contain a particular resource unit. It had to discover groups by
perform a potentially slow search (done by iterating over the set of processor
resource descriptors).

With this patch, the relationship between resource units and groups is stored in
the ResourceManager. That means, method 'use()' no longer has to search for
groups. This gives an average speedup of ~4-5% on a release build.

This patch also adds extra code comments in ResourceManager.h to better describe
the resource mask layout, and how resouce indices are computed from resource
masks.

llvm-svn: 350387

[Basic] Extend DiagnosticEngine to store and format Qualifiers.

Qualifiers can now be streamed into the DiagnosticEngine using
regular << operator. If Qualifiers are empty 'unqualified' will
be printed in the diagnostic otherwise regular qual syntax is
used.

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

llvm-svn: 350386

[AArch64] Add command-line option predres

Prediction control instructions are only
mandatory from v8.5a onwards but is optional
from Armv8.0-A. This patch adds a command
line option to enable it by it's own.

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

llvm-svn: 350385

Symtab: Remove one copy of symbol size computation code

Summary:
The implementation in CalculateSymbolSizes has been made redundant in
D19004, as this patch added another copy of size computation code into
InitAddressIndexes (which is called by CalculateSymbolSizes).

Reviewers: clayborg, jasonmolenda, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 350384

[CMake] Use XCODE_ATTRIBUTE properties for code signing and entitlements in Xcode

Summary: A post-commit comment to D55116 amended that this was the correct way for code signing in Xcode.

Reviewers: beanz

Reviewed By: beanz

Subscribers: mgorny, llvm-commits

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

llvm-svn: 350383

RangeMap.h: merge RangeDataArray and RangeDataVector

Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.

This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).

I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.

Reviewers: clayborg, teemperor, tberghammer

Subscribers: mgorny, JDevlieghere, lldb-commits

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

llvm-svn: 350380

[WebAssembly] Split the checking from the sorting logic.

Move the check for -1 and identical values outside the vector sorting code.
Compare functions need to be able to compare identical elements to be
conforming.

llvm-svn: 350379

[memcpyopt] Remove a few unnecessary isVolatile() checks. NFC

We already checked for isSimple() on the store.

llvm-svn: 350378

[OpenMP] Fix nvidia-cuda-toolkit detection on Debian/Ubuntu

The OpenMP runtime's cmake scripts do not correctly locate the
libdevice that the Debian/Ubuntu package nvidia-cuda-toolkit currently
includes, at least on my Ubuntu 18.04.1 installation.  This patch
fixes that for me.

This problem was discussed at length in D55269.  D40453 added a
similar adjustment in clang, but reviewers of D55269 concluded that,
for the OpenMP runtime, the right place to address this problem is in
cmake's CUDA support.  However, it was also suggested we could add a
workaround to OpenMP's cmake scripts now.  This patch contains such a
workaround, which I've tried to design so that it will have no harmful
effect if cmake improves in the future.

nvidia-cuda-toolkit also needs improvements because its intended
monolithic CUDA tree shim, /usr/lib/cuda, has many empty directories,
such as bin.  I reported that at:

<https://bugs.launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/+bug/1808999>

Reviewed By: grokos

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

llvm-svn: 350377

[lldb] Fix ObjCExceptionRecognizedStackFrame to populate the list of recognized arguments

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

llvm-svn: 350376

[lldb] Check SafeToCallFunctions before calling functions in GetExceptionObjectForThread

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

llvm-svn: 350375

[X86] Add post-isel peephole to fold KAND+KORTEST into KTEST if only the zero flag is used.

Doing this late so we will prefer to fold the AND into a masked comparison first. That can be better for the live range of the mask register.

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

llvm-svn: 350374

revert r350369: [x86] lower extracted fadd/fsub to horizontal vector math

There are non-codegen tests that need to be updated with this code change.

llvm-svn: 350373

Adopt SwiftABIInfo for WebAssembly.

Summary:
 - This adopts SwiftABIInfo as the base class for WebAssemblyABIInfo, which is in keeping with what is done for other targets for which Swift is supported.

 - This is a minimal patch to unblock exploration of WASM support for Swift (https://bugs.swift.org/browse/SR-9307)

Reviewers: rjmccall, sunfish

Reviewed By: rjmccall

Subscribers: ahti, dschuff, sbc100, jgravelle-google, aheejin, cfe-commits

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

llvm-svn: 350372

Fix MSVC visualizations for ActionResult and OpaquePtr

Mainly just fixing buggy code. Also removed unnecessary visualizers
for specializations of OpaquePtr

llvm-svn: 350371

[hwasan] Switch to 64 allocator with a dense size class map.

Summary:
Replace the 32-bit allocator with a 64-bit one with a non-constant
base address, and reduce both the number of size classes and the maximum
size of per-thread caches.

As measured on [1], this reduces average weighted memory overhead
(MaxRSS) from 26% to 12% over stock android allocator. These numbers
include overhead from code instrumentation and hwasan shadow (i.e. not a
pure allocator benchmark).

This switch also enables release-to-OS functionality, which is not
implemented in the 32-bit allocator. I have not seen any effect from
that on the benchmark.

[1] https://android.googlesource.com/platform/system/extras/+/master/memory_replay/

Reviewers: vitalybuka, kcc

Subscribers: kubamracek, cryptoad, llvm-commits

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

llvm-svn: 350370

[x86] lower extracted fadd/fsub to horizontal vector math

This would show up if we fix horizontal reductions to narrow as they go along,
but it's an improvement for size and/or Jaguar (fast-hops) independent of that.

We need to do this late to not interfere with other pattern matching of larger
horizontal sequences.

We can extend this to integer ops in a follow-up patch.

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

llvm-svn: 350369

symbols.enable-external-lookup=false on all hosts (not just OSX)

There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')

But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.

On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).

It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.

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

llvm-svn: 350368

[WebAssembly] Optimize Irreducible Control Flow

Summary:
Irreducible control flow is not that rare, e.g. it happens in malloc and
3 other places in the libc portions linked in to a hello world program.
This patch improves how we handle that code: it emits a br_table to
dispatch to only the minimal necessary number of blocks. This reduces
the size of malloc by 33%, and makes it comparable in size to asm2wasm's
malloc output.

Added some tests, and verified this passes the emscripten-wasm tests run
on the waterfall (binaryen2, wasmobj2, other).

Reviewers: aheejin, sunfish

Subscribers: mgrang, jgravelle-google, sbc100, dschuff, llvm-commits

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

Patch by Alon Zakai (kripken)

llvm-svn: 350367

[WebAssembly] Fixed disassembler not knowing about new brlist operand

Summary:
The previously introduced new operand type for br_table didn't have
a disassembler implementation, causing an assert.

Reviewers: dschuff, aheejin

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 350366

[WebAssembly] Made InstPrinter more robust

Summary:
Instead of asserting on certain kinds of malformed instructions, it
now still print, but instead adds an annotation indicating the
problem, and/or indicates invalid_type etc.

We're using the InstPrinter from many contexts that can't always
guarantee values are within range (e.g. the disassembler), where having
output is more valueable than asserting.

Reviewers: dschuff, aheejin

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 350365

[x86] add 512-bit vector tests for horizontal ops; NFC

llvm-svn: 350364

Fix check-hwasan with LLVM_BUILD_EXTERNAL_COMPILER_RT=ON

Add a forwarding target for check-hwasan in clang.

llvm-svn: 350363

[x86] add AVX512 runs for horizontal ops; NFC

llvm-svn: 350362

[cmake] Fix monorepo + LLVM_BUILD_EXTERNAL_COMPILER_RT=ON.

In cmake 3.10.2, if (${VARIABLE_NAME}) seems to always be false no
matter what documentation says (or maybe I just failed at reading).

Anyway, if (VARIABLE_NAME) seems to do what this code intended.

llvm-svn: 350361

TestQueues: Move the synchronisation code into the binary itself.

Thanks to Pavel Labath for the suggestion!

llvm-svn: 350360

[X86] Add test case for D56283.

This tests a case where we need to be able to compute sign bits for two insert_subvectors that is a liveout of a basic block. The result is then used as a boolean vector in another basic block.

llvm-svn: 350359

[x86] remove dead CHECK lines from test file; NFC

llvm-svn: 350358

[x86] split tests for FP and integer horizontal math

These are similar patterns, but when you throw AVX512 onto the pile,
the number of variations explodes. For FP, we really don't care about
AVX1 vs. AVX2 for FP ops. There may be some superficial shuffle diffs,
but that's not what we're testing for here, so I removed those RUNs.

Separating by type also lets us specify 'sse3' for the FP file vs. 'ssse3'
for the integer file...because x86.

llvm-svn: 350357

[x86] add common FileCheck prefix to reduce assert duplication; NFC

llvm-svn: 350356

[X86] Remove terrible DX Register parsing hack in parse operand. NFCI.

Fold hack special casing of (%dx) operand parsing into the related
hack for out*/in* instruction parsing.

llvm-svn: 350355

[DAGCombiner][x86] scalarize binop followed by extractelement

As noted in PR39973 and D55558:
https://bugs.llvm.org/show_bug.cgi?id=39973
...this is a partial implementation of a fold that we do as an IR canonicalization in instcombine:

// extelt (binop X, Y), Index --> binop (extelt X, Index), (extelt Y, Index)

We want to have this in the DAG too because as we can see in some of the test diffs (reductions),
the pattern may not be visible in IR.

Given that this is already an IR canonicalization, any backend that would prefer a vector op over
a scalar op is expected to already have the reverse transform in DAG lowering (not sure if that's
a realistic expectation though). The transform is limited with a TLI hook because there's an
existing transform in CodeGenPrepare that tries to do the opposite transform.

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

llvm-svn: 350354

[AVR] Update integration/blink.ll as we now generate sbi/cbi instructions.

Silence long standing test failure.

llvm-svn: 350353

[OpenMP] Add omp_get_device_num() and update several other device API functions

Add omp_get_device_num() function for 5.0 which returns the number of the
device the current thread is running on. Currently, we are leaving it to the
compiler to handle this properly if it is called inside target.

Also, did some cleanup and updating of duplicate device API functions (in both
libomp and libomptarget) to make them into weak functions that check for the
symbol from libomptarget, and will call the version in libomptarget if it is
present. If any additional device API functions are implemented also in
libomptarget in the future, we should add the dlsym calls to the host functions.
Also, if the omp_target_* functions are to be implemented for the host (this has
been requested), they should attempt to call the libomptarget versions as well.

Patch by Terry Wilmarth

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

llvm-svn: 350352

[CaptureTracking] Add a unit test for MaxUsesToExplore

llvm-svn: 350351

[AMDGPU] Fix scalar operand folding bug that causes SHOC performance regression.

Detailed description: SIFoldOperands::foldInstOperand iterates over the
operand uses calling the function that changes def-use iteratorson the
way. As a result loop exits immediately when def-use iterator is
changed. Hence, the operand is folded to the very first use instruction
only. This makes VGPR live along the whole basic block and increases
register pressure significantly. The performance drop observed in SHOC
DeviceMemory test is caused by this bug.

Proposed fix: collect uses to separate container for further processing
in another loop.

Testing: make check-llvm
SHOC performance test.

Reviewers: rampitec, ronlieb

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

llvm-svn: 350350

[UnrollRuntime] Move the DomTree verification under expensive checks

Suggested by Hal as done in r349871.

llvm-svn: 350349

Remove unused %host_cc lit pattern

It was added in r257236 but then the one use was removed in r309517. Since no
test should call %host_cc, remove the pattern.

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

llvm-svn: 350348

Reflow module.modulemap for readability

llvm-svn: 350347

Unbreak the modules build by splitting Target out into its own top-level module

llvm-svn: 350346

Revert "Resubmit rL345008 "Split MachinePipeliner code into header and cpp files""

This reverts commit r350290.

llvm-svn: 350345

Revert "[MachinePipeliner] Add missing header file to MachinePipeliner.h"

This reverts commit r350296.

llvm-svn: 350344

[llvm-objcopy] Fix buildbots on older compilers

llvm-svn: 350343

[MCStreamer] Use report_fatal_error in EmitRawTextImpl

Use report_fatal_error in MCStreamer::EmitRawTextImpl instead of
using errs() and explain the rationale behind it not being
llvm_unreachable() to save confusion for any future maintainers.

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

llvm-svn: 350342

[elfabi] Introduce tool for ELF TextAPI

Follow up for D53051

This patch introduces the tool associated with the ELF implementation of
TextAPI (previously llvm-tapi, renamed for better distinction). This
tool will house a number of features related to enalysis and
manipulation of shared object's exposed interfaces. The first major
feature for this tool is support for producing binary stubs that are
useful for compile-time linking of shared objects. This patch introduces
beginnings of support for reading binary ELF objects to work towards
that goal.

Added:

 - elfabi tool.
 - support for reading architecture from a binary ELF file into an
 ELFStub.
 - Support for writing .tbe files.

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

llvm-svn: 350341

Validate -add-plugin arguments.

-plugin already prints an error if the name of an unknown plugin is passed.
-add-plugin used to silently ignore that, now it errors too.

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

llvm-svn: 350340

Rename TapiTests to TextAPITests

This makes the target name consistent with how all the other unit tests are
named.

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

llvm-svn: 350339

[x86] add tests for buildvector with extracted element; NFC

llvm-svn: 350338

Fix typos in comments

llvm-svn: 350337

[llvm-objcopy][ELF] Implement a mutable section visitor that updates size-related fields (Size, EntrySize, Align) before layout.

Summary:
Fix EntrySize, Size, and Align before doing layout calculation.

As a side cleanup, this removes a dependence on sizeof(Elf_Sym) within BinaryReader, so we can untemplatize that.

This unblocks a cleaner implementation of handling the -O<format> flag. See D53667 for a previous attempt. Actual implementation of the -O<format> flag will come in an upcoming commit, this is largely a NFC (although not _totally_ one, because alignment on binary input was actually wrong before).

Reviewers: jakehehrlich, jhenderson, alexshap, espindola

Reviewed By: jhenderson

Subscribers: emaste, arichardson, llvm-commits

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

llvm-svn: 350336

Make -Wstring-plus-int warns even if when the result is not out of bounds

Summary: Patch by Arnaud Bienner

Reviewers: sylvestre.ledru, thakis, serge-sans-paille

Reviewed By: thakis

Subscribers: arphaman, dyung, anemet, llvm-commits, cfe-commits

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

llvm-svn: 350335

[UnrollRuntime] Add DomTree verification under debug mode

NFC: This adds the dom tree verification under debug mode at a point
just before we start unrolling the loop. This allows us to verify dom
tree at a state where it is much smaller and before the unrolling
actually happens.
This also implies we do not need to run -verify-dom-info everytime to
see if the DT is in a valid state when we transform the loop for runtime
unrolling.

llvm-svn: 350334