I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
  24 under clang/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
  std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
  !Long.Expression.equals("str") vs Long.Expression != "str".

Previously, isRoot() would return true for pointers with a base
of sizeof(InlineDescriptor), even if the actual metadata size of the
pointee was 0.

Being able to add custom dialects is one of the big missing pieces of
the C API. This change should make it achievable via IRDL. Hopefully
this should open custom dialect definition to non-C++ users of MLIR.

These can nearly always be folded into the existing cost of the branch, and brings the throughput costs of the scalarised gather/scatter code much closer to the llvm-mca/uica estimates

We were using the default implementations instead of the CRTP versions.

GCC 12 and 13 generate incorrect code for a pattern in the
tosa-to-tensor pass responsible for lowering tosa.reshape. This results
in the tosa.reshape lowering producing IR which fails to verify. I've
narrowed down the set of cmake flags needed to reproduce the issue to
this:

    cmake -G Ninja ../llvm \
      -DLLVM_ENABLE_PROJECTS="mlir" \
      -DLLVM_TARGETS_TO_BUILD=host \
      -DLLVM_ENABLE_PROJECTS=mlir \
      -DCMAKE_BUILD_TYPE="Release" \
      -DCMAKE_CXX_FLAGS_RELEASE="-O2" \
      -DCMAKE_CXX_FLAGS="-O2" \
      -DCMAKE_CXX_COMPILER=g++ \
      -DCMAKE_C_COMPILER=gcc

This is the failing test case:

func.func @fails_in_gcc_12(%arg0: tensor<?xf32>) -> tensor<1x1x1x?xf32>
{
%0 = tosa.reshape %arg0 {new_shape = array<i64: 1, 1, 1, -1>} :
(tensor<?xf32>) -> tensor<1x1x1x?xf32>
      return %0 : tensor<1x1x1x?xf32>
    }

This should lower to a tensor.expand_shape operation like so:

    func.func @foo(%arg0: tensor<?xf32>) -> tensor<1x1x1x?xf32> {
      %c0 = arith.constant 0 : index
      %dim = tensor.dim %arg0, %c0 : tensor<?xf32>
      %c1 = arith.constant 1 : index
%expanded = tensor.expand_shape %arg0 [[0, 1, 2, 3]] output_shape [1, 1,
1, %dim] : tensor<?xf32> into tensor<1x1x1x?xf32>
      return %expanded : tensor<1x1x1x?xf32>
    }

Under GCC 12/13 with the above cmake configuration, the
tensor.expand_shape looks like this

%2 = "tensor.expand_shape"(%arg0) <{reassociation = [[0, 1, 2, 3]],
static_output_shape = array<i64>}> : (tensor<?xf32>) ->
tensor<?x1x1x?xf32>

The key difference is the computed output type of `tensor<?x1x1x?xf32>`
rather than the expected `tensor<1x1x1x?xf32>`. This expand_shape fails
to verify with this error message:

error: 'tensor.expand_shape' op expected number of static shape dims to
be equal to the output rank (4) but found 0 inputs instead

The problematic code is calculating the intermediate shape of the
generated tensor.expand_shape operation in the
expand_shape/collapse_shape sequence that implements tosa.reshape.

    // Compute result shape
    bool resultIsStatic = true;
    auto resultShape = llvm::map_to_vector(newShape, [&](int64_t size) {
      // Omitted

// If we do not know the total size of the tensor, keep this dimension
      // dynamic in the result shape.
      if (!inputIsStatic) {
        resultIsStatic = false;
        return ShapedType::kDynamic;
      }
    });

    if (resultIsStatic) {
      // do something
      return;
    }

    // do something else
    return;

The failure point seems to be the update of the resultIsStatic variable
in the lambda body. The assignment of false is not propagated to the use
in the if-statement, resulting in the branch being taken when it should
not.

I've found several modification to the code that gets around the bug.
The version I settled on is one which makes the logic a little more
obvious.

This is a follow-up patch for #74199

Follow-up to https://github.com/llvm/llvm-project/pull/88257

[P1787R6](https://wg21.link/p1787r6):
> [CWG1820](https://cplusplus.github.io/CWG/issues/1820.html) is
resolved by requiring that a qualified declarator-id declare an entity.

P1787R6 changes wording of [dcl.pre]/9. Quote from the current draft
([[dcl.pre]/5](https://eel.is/c++draft/dcl.pre#5)):
> If a
[declarator-id](https://eel.is/c++draft/dcl.decl.general#nt:declarator-id)
is a name, the
[init-declarator](https://eel.is/c++draft/dcl.decl.general#nt:init-declarator)
and (hence) the declaration introduce that
name[.](https://eel.is/c++draft/dcl.pre#5.sentence-1)
> [Note [3](https://eel.is/c++draft/dcl.pre#note-3): Otherwise, the
[declarator-id](https://eel.is/c++draft/dcl.decl.general#nt:declarator-id)
is a
[qualified-id](https://eel.is/c++draft/expr.prim.id.qual#nt:qualified-id)
or names a destructor or its
[unqualified-id](https://eel.is/c++draft/expr.prim.id.unqual#nt:unqualified-id)
is a [template-id](https://eel.is/c++draft/temp.names#nt:template-id)
and no name is
introduced[.](https://eel.is/c++draft/dcl.pre#5.sentence-2)
— end note]

This should fix buildbot failures in:
https://lab.llvm.org/buildbot/#/builders/5/builds/43303
https://lab.llvm.org/buildbot/#/builders/168/builds/20347

Align with DataReader::readProfile that sets entry block counts from
FuncBranchData->EntryData.

Test Plan: updated bolt-address-translation-yaml.test

Align BAT YAML to fdata profile.

Test Plan: updated register-fragments-bolt-symbols.s

Reviewers: dcci, rafaelauler, ayermolo, maksfb

Reviewed By: dcci

Pull Request: https://github.com/llvm/llvm-project/pull/91773

[clang-tidy] `readability-simplify-boolean-expr` avoid to warn expression expand from macro when ``IgnoreMacro`` option is enabled. (#91757)

Fixes: #91487

There are 100+ references.
Use a wrapper similar to a623a4c8

Remove FormatToken::isSimpleTypeSpecifier() and call
Token::isSimpleTypeSpecifier(LangOpts) instead.

The uses have been removed by commit 2b5cd8be

The `APInt *` version is pretty useless as any case one needs an
`APInt *` out, they could just replace whatever they have the
`m_Checked...` lambda with direct checks on the `APInt`.

Leaving other helpers such as `m_Negative`, `m_Power2`,
etc... unchanged as the `APInt` out version is used mostly for
convenience and rarely change functionality when converted output a
`Constant *`.

Closes #91377

Reverts llvm/llvm-project#91668

Fixes: https://lab.llvm.org/buildbot/#/builders/192/builds/9313

`vp.reduce.fmaximum/fminimum` are the VP version of
`vector.reduce.fmaximum/fminimum`.

A few tests were checking for all driver flags.
We should revert this commit when we revert #91811

libfuzzer's -jobs option will, depending on the number of CPUs, spin up
a
WorkerThread and end up printing the log file using CopyFileToErr.
This leads to an MSan false positive. This patch disables the MSan
interceptor checks,
similarly to other instances in https://reviews.llvm.org/D48891

Side-note: this false positive issue first appeared when printf()
was replaced by puts() (90b4d1bc).
The interceptor check was always present; however, MSan does not
check_printf by default.

We can extract each extension as we process them without much
complexity.

Initializes the MachineFunctionInfo for unittest introduced in #88257

Additionally, also rephrases the test condition considering the abort/exit does not occur within emitKernel but is generally triggered through the Ctx.hadError() call.

Summary:
GPUs like to execute instructions in the background until something
excplitely consumes them. We are working on adding some
microbenchmarking code, which requires flushing the pending memory
operations beforehand. This patch simply adds these utility functions
that will be used in the near future.

These are just bit operations, exactly the same as with f16.

This partially reverts b86e0992.

Just the default is changed back, on the Driver side.
No Frontend changes.
The positive spelling of the flag is undeprecated.

No documentation changes or changelog entries because we plan to revert
this revert as soon as https://github.com/llvm/llvm-project/issues/62529
is fixed.

Revert "[Pipelines] Do not run CoroSplit and CoroCleanup in LTO pre-link pipeline (#90310)" and related patches

This change is incorrect when thinlto and asan are enabled, and this can
be observed by adding `-fsanitize=address` to the provided
coro-elide-thinlto.cpp test. It results in the error "Coroutines cannot
handle non static allocas yet", and ASan introduces a dynamic alloca.

In other words, we must preserve the invariant that CoroSplit runs
before ASan. If we move CoroSplit to the post post-link compile stage,
ASan has to be moved to the post-link compile stage first.  It would
also be correct to make CoroSplit handle dynamic allocas so the pass
ordering doesn't matter, but sanitizer instrumentation really ought to
be last, after coroutine splitting.

This reverts commit bafc5f42.
This reverts commit b1b1bfa7.
This reverts commit 0232b77e.
This reverts commit fb2d3056.
This reverts commit 1cb33713.
This reverts commit cd68d7b3.

This tool doesn't work unless it's signed with the entitlements used
here. We should probably consider using the
macos_command_line_application rule from rules_apple which manages this
more flexibly for us, but for now this works. This uses apple_genrule as
opposed to genrule since the former encodes the Xcode environment info
into the action so it is correctly invalidated if that changes.

Some functions and subroutines are available in device context
(device/global). These functions have interfaces declared in the
`cudadevice` module.

This patch adds interfaces as `__cuda_device_builtins_<fctname>` in a
builtin module and they are USE'd rename in the `cudadevice` module. The
module is implicitly used in device/global subprograms.

The builtin module only contains procedures from section 3.6.4 for now.

Fix the problem:
https://github.com/llvm/llvm-project/pull/90663#issuecomment-2105164917
by enhancing a double-check for #90663

The directory was created by 2f1fe9a3
(2020).

Pull Request: https://github.com/llvm/llvm-project/pull/91783

Offset annotation is used in writing BAT tables.

Test Plan: updated sctc-bug4.test

When generating block terminators in `genFIR(Evaluation)`, treat
`Directives` with nested evaluations the same way as `Constructs` to
determine the successor block.

This fixes https://github.com/llvm/llvm-project/issues/91526