Summary:
export_symbols.py discards duplicate symbols, assuming they have public definitions, so if we end
up calling it with duplicate libraries we will end up with an inaccurate export list.

Reviewers: jasonliu, stevewan, john.brawn

Reviewed By: john.brawn

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

Rename LIBXML2_DEFINED to LLDB_ENABLE_LIBXML2 and pass it through
Config.h instead of a global define.

Summary: Speculative fix after 34ef51b5 broke the lldb buildbot on libc++ tests.

Reviewers: echristo, EricWF

Subscribers: ldionne, lldb-commits

Tags: #lldb

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

type sugar.

We previously missed the attribute in a lot of cases in C++, because
there's often other type sugar there (eg, ElaboratedType).

Revert "[SDAG] remove use restriction in isNegatibleForFree() when called from getNegatedExpression()"

This reverts commit d1f0bdf2.
The patch can cause infinite loops in DAGCombiner.

Summary: The test logic for running libc++ tests only looks to see if `/usr/include/c++/v1` exists. This adds a fallback for including libc++ tests as long as `$(CC) -stdlib=libc++` works.

Reviewers: labath, EricWF

Subscribers: ldionne, lldb-commits

Tags: #lldb

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

GCC 5 doesn't support `if constexpr`, so we need to do old-style tag
dispatching.

We simply turn off the parts of the tests that require exceptions.

According to OpenMP 5.0, if clause can be used in for simd directive. If
condition in the if clause if false, the non-vectorized version of the
loop must be executed.

This flaky test that I added really gives our CI a lot of headaches.
Although I was never able to reproduce this locally, it sporadically
hangs/fails on our bots.  I decided to silently pass the test whenever
we are unable to setup the proper test condition after 10 retries.  This
is of course suboptimal and a last recourse.  Please let me know if you
know how to test this better.

rdar://57844626

[LegalizeTypes] In SoftenFloatRes_FP_EXTEND, move the check for input already being promoted above the check for fp16 converting to something other than fp32.

The fp16 to larger than fp32 inserts an extend that need to
re-legalized if fp16 is promoted. But if we check for fp16
promotion first, then we can avoid emiting the fp_extend all
together.

This patch also re-names the existing fuzzing unit tests so they
actually run.

Fixes issue encountered in D56362, where I tried to use a
SmallSetVector<Instruction*, 128> with an excessively large number
of inline elements. This triggers an "Must allocate more buckets
than are inline" assertion inside allocateBuckets() under certain
usage patterns.

The issue is as follows: The grow() method is used either to grow
the map, or to rehash it and remove tombstones. The latter is done
if the fraction of empty (non-used, non-tombstone) elements is
below 1/8. In this case grow() is invoked with the current number
of buckets.

This is currently incorrectly handled for dense maps using the small
rep. The current implementation will switch them over to the large
rep, which violates the invariant that the large rep is only used
if there are more than InlineBuckets buckets.

This patch fixes the issue by staying in the small rep and only
moving the buckets. An alternative, if we do want to switch to the
large rep in this case, would be to relax the assertion in
allocateBuckets().

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

This is the initial patch for the OpenMP-IR-Builder, as discussed on the
mailing list ([1] and later) and at the US Dev Meeting'19.

The design is similar to D61953 but:
  - in a non-WIP status, with proper documentation and working.
  - using a OpenMPKinds.def file to manage lists of directives, runtime
    functions, types, ..., similar to the current Clang implementation.
  - restricted to handle only (simple) barriers, to implement most
    `#pragma omp barrier` directives and most implicit barriers.
  - properly hooked into Clang to be used if possible (D69922).
  - compatible with the remaining code generation.

Parts have been extracted into D69853.

The plan is to have multiple people working on moving logic from Clang
here once the initial scaffolding (=this patch) landed.

[1] http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html

Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim

Subscribers: mgorny, hiraditya, bollu, guansong, jfb, cfe-commits, llvm-commits, penzn, ppenzin

Tags: #clang, #llvm

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

I don't think this test case can be handled correctly on AAPCS64.
The ABI says that the caller passes the address of the return object
in x8.  x8 is a caller-spilled (aka "volatile") register, and the
function is not required to preserve x8 or to copy the address back
into x8 on function exit like the SysV x86_64 ABI does with rax.
(from aapcs64: "there is no requirement for the callee to preserve the
value stored in x8")

From my quick reading of ABISysV_arm64, I worry that it may actually be
using the value in x8 at function exit, assuming it still has the
address of the return object -

    if (is_return_value) {
      // We are assuming we are decoding this immediately after returning from
      // a function call and that the address of the structure is in x8
      reg_info = reg_ctx->GetRegisterInfoByName("x8", 0);

This will work on trivial test programs / examples, but if the function
does another function call, or overwrites x8 as a scratch register, lldb
will provide incorrect values to the user.

ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value
as unavailable so we're providing incorrect values to the user all
the time.  I expect my fix will be to make ABIMacOSX_arm64 flag
the return value as unretrievable, unless I've misread the ABI.

This is equivalent to the existing `import_name` and `import_module`
attributes which control the import names in the final wasm binary
produced by lld.

This maps the existing

This attribute currently requires a string rather than using the
symbol name for a couple of reasons:

1. Avoid confusion with static and dynamic linking which is
   based on symbol name.  Exporting a function from a wasm module using
   this directive is orthogonal to both static and dynamic linking.
2. Avoids name mangling.

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

Fix for https://bugs.llvm.org/show_bug.cgi?id=40846.

This adds a combine for cases where a (a + b) < a style overflow
check is performed, but with a + b being the result of
uadd.with.overflow, so the overflow result is also already available
and we can just use it. Subsequently GVN/CSE will deduplicate the extracts.

We can run into this situation if you have both a uadd.with.overflow
and a manual add + overflow check in the same function (on the same
operands), in which case GVN will rewrite the add to the with.overflow
result and leave you with this pattern.

The implementation is a bit ugly because I'm handling the various
canonicalization edge cases.

This does not yet handle the negated version of this pattern.

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

This patch introduced additional PointerEscape callbacks after conservative
calls for output parameters. This should not really affect the current
checkers but the upcoming FuchsiaHandleChecker relies on this heavily.

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

If the pointer was loaded/stored before the null check, the check
is redundant and can be removed. For now the optimizers do not
remove the nullptr check, see https://gcc.godbolt.org/z/H2r5GG.
The patch allows to use more nonnull constraints. Also, it found
one more optimization in some PowerPC test. This is my first llvm
review, I am free to any comments.

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

Tests for D71177.

The checker was trying to analyze the body of every method in Objective-C
@implementation clause but the sythesized accessor stubs that were introduced
into it by 2073dd2d have no bodies.

While analyzing code `memcmp(a, NULL, n);', where `a' has an unconstrained
symbolic value, the analyzer was emitting a warning about the *first* argument
being a null pointer, even though we'd rather have it warn about the *second*
argument.

This happens because CStringChecker first checks whether the two argument
buffers are in fact the same buffer, in order to take the fast path.
This boils down to assuming `a == NULL' to true. Then the subsequent check
for null pointer argument "discovers" that `a' is null.

Don't take the fast path unless we are *sure* that the buffers are the same.
Otherwise proceed as normal.

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

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

Fix for https://bugs.llvm.org/show_bug.cgi?id=44236. This code was
originally introduced in rG36512330.
However, the attribute copying was done in the wrong place (in general
call replacement, not thunk generation) and a proper fix was
implemented in D12581.

Previously this code was just unnecessary but harmless (because
FunctionComparator ensured that the attributes of the two functions
are exactly the same), but since byval was changed to accept a type
this copying is actively wrong and may result in malformed IR.

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

Summary:
The following intrinsics for unary narrowing operations are added:
 * @llvm.aarch64.sve.sqxtnb
 * @llvm.aarch64.sve.uqxtnb
 * @llvm.aarch64.sve.sqxtunb
 * @llvm.aarch64.sve.sqxtnt
 * @llvm.aarch64.sve.uqxtnt
 * @llvm.aarch64.sve.sqxtunt

Reviewers: sdesmalen, rengolin, efriedma

Reviewed By: efriedma

Subscribers: tschuett, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

I'm not sure how .. is resolved on Windows. Disable it for now to make
the bots happy again.

This fixes crashes with $noreg operands.

The default characters for trim, ltrim and rtrim are " \t\n\v\f\r" but
only spaces were tested. Test that the others are trimmed as well.

This is an alternate fix for the bug discussed in D70595.
This also includes minimal tests for other in-tree targets
to show the problem more generally.

We check the number of uses as a predicate for whether some
value is free to negate, but that use count can change as we
rewrite the expression in getNegatedExpression(). So something
that was marked free to negate during the cost evaluation
phase becomes not free to negate during the rewrite phase (or
the inverse - something that was not free becomes free).
This can lead to a crash/assert because we expect that
everything in an expression that is negatible to be handled
in the corresponding code within getNegatedExpression().

This patch skips the use check during the rewrite phase.
So we determine that some expression isNegatibleForFree
(identically to without this patch), but during the rewrite,
don't rely on use counts to decide how to create the optimal
expression.

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

directive.

Fixed capturing of the if condition if no modifer was specified in this
condition. Previously could capture it only in outer region and it could
lead to a compiler crash.

When writing out a profile, avoid allocating a page on the stack for the
purpose of writing out zeroes, as some embedded environments do not have
enough stack space to accomodate this.

Instead, use a small, fixed-size zero buffer that can be written
repeatedly.

For a synthetic file with >100,000 functions, I did not measure a
significant difference in profile write times. We are removing a
page-length zero-fill `memset()` in favor of several smaller buffered
`fwrite()` calls: in practice, I am not sure there is much of a
difference. The performance impact is only expected to affect the
continuous sync mode (%c) -- zero padding is less than 8 bytes in all
other cases.

rdar://57810014

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

Extend the virtual working directory test with a few edge cases that are
not currently tested.

According to OpenMP 5.0, if clause can be used in for simd directive. If
condition in the if clause if false, the non-vectorized version of the
loop must be executed.

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.

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

Summary:
The original design used --foo but the upstream complained that ELF only
options should be -z foo. See https://sourceware.org/ml/binutils/2019-04/msg00151.html
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=8bf6d176b0a442a8091d338d4af971591d19922c
made the rename.

Our --force-bti and --pac-plt implement the same functionality, so it
seems wise to be consistent with GNU ld.

Reviewed By: peter.smith

Subscribers: emaste, arichardson, kristof.beyls, llvm-commits

Tags: #llvm

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