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

Debug intrinsics sometimes end up with empty metadata location operands. The
debug intrinsic interfaces return nullptr when retrieving location operand in
this case.

Skip empty-metadata dbg.declares to avoid dereferencing the nullptr. This
doesn't affect the final debug info in any way.

Reviewed By: jryans

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

Debug intrinsics sometimes end up with empty metadata location operands. The
debug intrinsic interfaces return nullptr when retrieving location operand in
this case.

When assignment tracking is not enabled a dbg.declare with a nullptr location
operand is skipped. Do the same when assignment tracking is enabled (a nullptr
address component of a dbg.assign is already handled correctly.

Reviewed By: jmorse

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

There are now two entry points. One for shaped values and one for index-typed values. This addresses a comment in D146524.

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

In line 68, func getBlockFreqRelativeToEntryBlock assume getEntryFreq() is
non-zero, but the function could return 0, add assert to confirm it.

Reviewed By: HaohaiWen

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

To ensure that we have a pointee for the `PointerValue`, we also create
storage locations for `FunctionDecl`s referenced in the function under analysis.

Reviewed By: gribozavr2

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

May be related to PR62175

This reverts commit a3fd060d.

Revert "[ValueTracking] Apply the isKnownNonZero techniques in `ashr`/`lshl` to `shl` and vice-versa"

May be related to PR62175

This reverts commit 57590d1d.

Reviewed By: xazax.hun, gribozavr2

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

If Y is non-zero we can simplify the ge/le -> gt/lt

`(X ^ Y_NonZero) u>= X` --> `(X ^ Y_NonZero) u> X`
    - https://alive2.llvm.org/ce/z/k482NQ
`(X ^ Y_NonZero) u<= X` --> `(X ^ Y_NonZero) u< X`
    - https://alive2.llvm.org/ce/z/TuUDGy
`(X ^ Y_NonZero) s>= X` --> `(X ^ Y_NonZero) s> X`
    - https://alive2.llvm.org/ce/z/vXQypR
`(X ^ Y_NonZero) s<= X` --> `(X ^ Y_NonZero) s< X    `
    - https://alive2.llvm.org/ce/z/fbUq-z

Reviewed By: spatel

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

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

For all shifts we can apply the same two optimizations.

    1) `ShiftOp(KnownVal.One, Max(KnownCnt)) != 0`
        -> result is non-zero
    2) If already known `Val != 0` and we only shift out zeros (based
       on `Max(KnownCnt)`)
        -> result is non-zero

The former exists for `shl` and the latter (for constant `Cnt`) exists
for `ashr`/`lshr`.

This patch improves the latter to use `Max(KnownCnt)` instead of
relying on a constant shift `Cnt` and applies both techniques for all
shift ops.

Reviewed By: nikic

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

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

This is more RAM and CPU efficient than allocating entire page per
context, and this approach is used by other sanitizers already.

With the patch "create_thread_loop2.cpp.tmp 5000" is 30% faster.

Reported by Coverity:

Copy without assign
This class has a user-defined copy constructor but no user-defined assignment operator. If the copy constructor is necessary to manage owned resources then a corresponding assignment operator is usually required. If an object of this type is assigned memory leaks and/or use-after-free errors may occur. Note that a compiler-generated assignment operator will perform only a bit-wise copy for any fields that do not have their own assignment operators defined.

Class has user-written copy constructor but no user-written assignment operator

copy_without_assign: Class <unnamed>::DeclUseTracker has a user-written copy constructor <unnamed>::DeclUseTracker::DeclUseTracker(<unnamed>::DeclUseTracker const &) =delete but no corresponding user-written assignment operator.

Reviewed By: aaron.ballman

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

The condition Opcode <= std::numeric_limits<int>::max() will
always be true here.

Reviewed By: skan

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

If this test fails, the error message isn't helpful:

```
self.assertEqual(len(threads), 1,
AssertionError: 0 != 1 : Stopped at breakpoint in exec'ed process
```

This change adds asserts to verify that:
1. The process is stopped
2. For each thread, that the stop reason is None, or Breakpoint

The latter will indicate if execution has stopped for some other reason, and if so what
that reason is.

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

Mark the two dfsan tests that are known to be broken on glibc-2.37
as XFAIL, to make the test suite start passing on Gentoo again.

Bug: https://github.com/llvm/llvm-project/issues/60678

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

Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. [NFC] Fix auto keyword use without an & causes the copy of an object of type SimpleRegistryEntry in clang::getAttributePluginInstances()

2. [NFC] Fix auto keyword use without an & causes the copy of an object of type tuple in CheckStmtInlineAttr<clang::NoInlineAttr, 2>(clang::Sema &, clang::Stmt const *, clang::Stmt const *, clang::AttributeCommonInfo const &)

3. [NFC] Fix auto keyword use without an & causes the copy of an object of type QualType in <unnamed>::SystemZTargetCodeGenInfo::isVectorTypeBased(clang::Type const *, bool)

4. [NFC] Fix auto keyword use without an & causes the copy of an object of type Policy in <unnamed>::RISCVIntrinsicManagerImpl::InitIntrinsicList()

5. [NFC] Fix auto keyword use without an & causes the copy of an object of type pair in checkUndefinedButUsed(clang::Sema &)

Reviewed By: tahonermann

Differential Revision: <https://reviews.llvm.org/D147543>

I noticed _Complex was missing for the long double case.
I might be missing something, but it looks like the compiler
does not call the C wrappers directly. Do we need to keep
the complex-reduction.[ch] at all?

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

We failed to cache queries without an exclusion set that resulted in
non-reachable results. That is obviously bad as changes to liveness can
influence the result.

Fixes: https://github.com/llvm/llvm-project/issues/61883

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

When input is DWP with DWARF5 bolt wasn't handling correctly CUs that didn't
have TU references. Which resulted in a crash.

Reviewed By: maksfb

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

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

Not needed.

This reverts commit e864e6f2.

https://lab.llvm.org/buildbot/#/builders/127/builds/46887/steps/4/logs/stdio

Instead of taking a `const std::string &` we can take an
`llvm::StringRef`. The motivation for this change is that many of the
callers of `ParseJSON` end up creating a temporary `std::string` from an existing
`StringRef` or `const char *` in order to satisfy the API. There's no
reason we need to do this.

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

Asan detects heap-use-after-free, see D147892.

This reverts commit 4fc19035.
This reverts commit 668045eb.

This patch allows access to callbacks registered by TargetMachines to allow custom pipelines to run those callbacks.

Reviewed By: aeubanks

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

The functionality added by https://reviews.llvm.org/D145803 is gated by
lldb tuning, so we need to build the test programs with `-glldb` to make
these tests print the expected preferred name.

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

The `clang:ast` and `clang:builtin_headers_gen` targets currently use hardcoded `external/llvm-project`
paths to access generated headers.

With bzlmod this path becomes dependent on the module name, module version and module extension,
so we need a more dynamic approach.

Does not affect the WORKSPACE build.

Reviewed By: GMNGeoffrey, #bazel_build

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

We are already doing this for depthwise convolution and pooling.
This helps to preserve the promotion semantics from Linalg op
definitions to lower layers.

Along the way, fixed the type mismatch issue in the existing
`promote` implementation.

Reviewed By: kuhar

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

Use ELF TLS by default instead of emulated TLS for Android build targets when
the API level is >= 29.

Android Q features full TLS support. See release notes
(https://developer.android.com/preview/features#elf-tls) and implementation details
(https://android.googlesource.com/platform/bionic/+/master/docs/elf-tls.md#Workaround_Use-Variant-2-on-arm32_arm64).

Reviewed By: rprichard, danalbert

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