By default, all traits in the OpenMP context selector have to match for
it to be acceptable. Though, we sometimes want a single property out of
multiple to match (=any) or no match at all (=none). We offer these
choices as extensions via
  `implementation={extension(match_{all,any,none})}`
to the user. The choice will affect the entire context selector not only
the traits following the match property.

The first user will be D75788. There we can replace
```
  #pragma omp begin declare variant match(device={arch(nvptx64)})
  #define __CUDA__

  #include <__clang_cuda_cmath.h>

  // TODO: Hack until we support an extension to the match clause that allows "or".
  #undef __CLANG_CUDA_CMATH_H__

  #undef __CUDA__
  #pragma omp end declare variant

  #pragma omp begin declare variant match(device={arch(nvptx)})
  #define __CUDA__

  #include <__clang_cuda_cmath.h>

  #undef __CUDA__
  #pragma omp end declare variant
```
with the much simpler
```
  #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)})
  #define __CUDA__

  #include <__clang_cuda_cmath.h>

  #undef __CUDA__
  #pragma omp end declare variant
```

Reviewed By: mikerice

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

If we have a function definition in `omp begin/end declare variant` it
is a specialization of a base function with the same name and
"compatible" type. Before, we just created a declaration for the base.
With this patch we try to find an existing declaration first and only
create a new one if we did not find any with a compatible type. This is
preferable as we can tolerate slight mismatches, especially if the
specialized version is "more constrained", e.g., constexpr.

Reviewed By: mikerice

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

This revision removes the reliance of Promotion on `linalg.slice` which is meant
for the rank-reducing case.

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

It seems one target was missed in D77666 which kept some bots red [0].

[0] http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/12079/steps/build%20stage%201/logs/stdio

Invoke `keep()` on the output file of `mlir-opt` in case the invocation of `MlirOptMain` was successful, to make sure the output file is not deleted on exit from `mlir-opt`.
Fixes a similar problem in `standalone-opt` from the example for an out-of-tree, standalone MLIR dialect.

This revision also adds a missing parameter to the invocation of `MlirOptMain` in `standalone-opt`.

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

Summary:
ComputeValueKnownInPredecessorsImpl is the main folding mechanism in
JumpThreading.cpp.  To avoid potential infinite recursion while
chasing use-def chains, it uses:

  DenseSet<std::pair<Value *, BasicBlock *>> &RecursionSet

to keep track of Value-BB pairs that we've processed.

Now, when ComputeValueKnownInPredecessorsImpl recursively calls
itself, it always passes BB as is, so the second element is always BB.

This patch simplifes the function by dropping "BasicBlock *" from
RecursionSet.

Reviewers: wmi, efriedma

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

lit supports `--time-tests` which will report the 20 slowest tests and
print a nice histogram for test times.  This change prints this list and
the histogram rows by decreasing test times.  After all, we are most
interested in the slowest tests.

This reverts commit a8c8b627. It causes
intermittent

    Clang :: SemaObjC/parameterized_classes_subst.m

test failures on various bots.

Reviewers: EricWF, #libc

Reviewed By: EricWF, #libc

Subscribers: broadwaylamb, libcxx-commits

Tags: #libc

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

Summary:
Re-used the IR-level debugify for the most part. The MIR-level code then
adds locations to the MachineInstrs afterwards based on the LLVM-IR debug
info.

It's worth mentioning that the resulting locations make little sense as
the range of line numbers used in a Function at the MIR level exceeds that
of the equivelent IR level function. As such, MachineInstrs can appear to
originate from outside the subprogram scope (and from other subprogram
scopes). However, it doesn't seem worth worrying about as the source is
imaginary anyway.

There's a few high level goals this pass works towards:
* We should be able to debugify our .ll/.mir in the lit tests without
  changing the checks and still pass them. I.e. Debug info should not change
  codegen. Combining this with a strip-debug pass should enable this. The
  main issue I ran into without the strip-debug pass was instructions with MMO's and
  checks on both the instruction and the MMO as the debug-location is
  between them. I currently have a simple hack in the MIRPrinter to
  resolve that but the more general solution is a proper strip-debug pass.
* We should be able to test that GlobalISel does not lose debug info. I
  recently found that the legalizer can be unexpectedly lossy in seemingly
  simple cases (e.g. expanding one instr into many). I have a verifier
  (will be posted separately) that can be integrated with passes that use
  the observer interface and will catch location loss (it does not verify
  correctness, just that there's zero lossage). It is a little conservative
  as the line-0 locations that arise from conflicts do not track the
  conflicting locations but it can still catch a fair bit.

Depends on D77439, D77438

Reviewers: aprantl, bogner, vsk

Subscribers: mgorny, hiraditya, llvm-commits

Tags: #llvm

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

Just delete the deprecated overload because nothing uses it.

Summary: 'it' may get invalidated when recursing into optional groups. This revision refactors the inner loop to avoid the need to compare the iterator after invalidation.

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

dso_local leads to direct access even if the definition is not within this compilation unit (it is
still in the same linkage unit). On ELF, such a relocation (e.g. R_X86_64_PC32) referencing a
STB_GLOBAL STV_DEFAULT object can cause a linker error in a -shared link.

If the linkage is changed to available_externally, the dso_local flag should be dropped, so that no
direct access will be generated.

The current behavior is benign, because -fpic does not assume dso_local
(clang/lib/CodeGen/CodeGenModule.cpp:shouldAssumeDSOLocal).
If we do that for -fno-semantic-interposition (D73865), there will be an
R_X86_64_PC32 linker error without this patch.

Reviewed By: tejohnson

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

Broke builders that emit different diagnostics. e.g.:

error: 'warning' diagnostics seen but not expected:
  Line 13: alias declarations are a C++11 extension
  Line 20: alias declarations are a C++11 extension

This reverts commit ff878137.

Error messages for the custom assembly format are difficult to understand
because there are no line numbers.  This happens because the assembly format
is parsed as a standalone line, separate from it's parent file, with no useful
location information.  Fixing this properly probably requires quite a bit
of invasive plumbing through the SourceMgr, similar to how included files
are handled

This proposal is a less invasive short term solution.  When generating an
error message we generate an additional note which at least properly describes
the operation definition the error occured in, if not the actual line number
of the assemblyFormat definition.

A typical message is like:

error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred
  $operand type($result) attr-dict
  ^
/src/llvm-project/mlir/test/mlir-tblgen/op-format-spec.td:296:1: note: in custom assembly format for this operation
def ZCoverageInvalidC : TestFormat_Op<"variable_invalid_c", [{
^
note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format
  $operand type($result) attr-dict
  ^

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

The messages are somewhat cryptic, since they are not complete sentences,
include lots of ambiguous words, like 'format' which are hard to parse,
and include names from the users code which may, or may not make sense in
the context of the message.  Start to clean this up and provide some
guidance for fixes.

Also, add a test for one of the messages which didn't have a test at all.

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

Summary: These aren't available on Android in all configurations.

Reviewers: EricWF, mclow.lists, #libc, ldionne

Reviewed By: EricWF, #libc, ldionne

Subscribers: broadwaylamb, dexonsmith, ldionne, krytarowski, libcxx-commits

Tags: #libc

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

When the EHHeaderInfo object filled by decodeEHHdr has fde_count == 0,
findFDE does the following:

- sets low = 0 and len = hdrInfo.fde_count as a preparation to start a
  binary search
- because len is 0, the binary search loop is skipped
- the code still tries to find a table entry at
  hdrInfo.table + low * tableEntrySize, and decode it.

This is wrong when fde_count is 0, and trying to decode a table entry
that isn't there will lead to reading garbage offsets and can cause
segfaults.

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

No need to capture the global variable marked as shared in the OpenMP
region, the original variable can be used.

Fix the error of show-prof-info.test on some platforms without zlib.

The common profile usage is to collect profile from a target and then use the profile to guide the optimized build for the same target. There are some cases that no profile can be collected for a target. In those cases, although no full profile is available, it is possible to have some partial profile collected from other targets to optimize common libraries and utilities. A flag is needed to tell the partial profile from the full profile apart, so compiler can use different strategy for them.

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

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

The pass tablegen backend now generates base classes instead of utilities, so this revision updates the documentation to reflect that.

It has never been used, and it actually doesn't really work because it
assumes that the target supports Python. Instead, it's better to just
use `!` since we're running ShTests in system shells anyway.

Previous fix missed a check to willEmitRemarks, causing remarks to
always be enabled for LTO.

This is undefined behavior. Found by asan's detect_container_overflow.

Summary:
This is much cleaner, and fits the same structure as many other tablegen backends. This was not done originally as the CRTP in the pass classes made it overly verbose/complex.

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

This revision removes all of the CRTP from the pass hierarchy in preparation for using the tablegen backend instead. This creates a much cleaner interface in the C++ code, and naturally fits with the rest of the infrastructure. A new utility class, PassWrapper, is added to replicate the existing behavior for passes not suitable for using the tablegen backend.

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

ModulePass doesn't provide any special utilities and thus doesn't give enough benefit to warrant a special pass class. This revision replaces all usages with the more general OperationPass.

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

This reduces max-rss of sqlite compilation by 2.5%.

Summary:
Add directive to indicate the location to give to op being created. This
directive is optional and if unused the location will still be the fused
location of all source operations.

Currently this directive only works with other op locations, reusing an
existing op location or a fusion of op locations. But doesn't yet support
supplying metadata for the FusedLoc.

Based off initial revision by antiagainst@ and effectively mirrors GlobalIsel
debug_locations directive.

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

Summary:
The buffer protocol does not allow us to just call PyBuffer_Release
and assume the buffer will still be there.   Most things that implement the
buffer protocol will let us get away with that, but not all.   We need
to release it at the end of the SWIG wrapper.

Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

Summary:
* Removal of FxpMathOps was discussed on the mailing list.
* Will send a courtesy note about also removing the Quantizer (which had some dependencies on FxpMathOps).
* These were only ever used for experimental purposes and we know how to get them back from history as needed.
* There is a new proposal for more generalized quantization tooling, so moving these older experiments out of the way helps clean things up.

Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, llvm-commits

Tags: #llvm

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