`DataAggregator::recordTrace` serves two purposes:
  - Attaching LBR fallthrough ("trace") information to CFG (`getBranchInfo`),
    which eventually gets emitted as YAML profile.
  - Populating vector of offsets that gets added to `FuncBranchData`, which
    eventually gets emitted as fdata profile.

`recordTrace` is invoked from `getFallthroughsInTrace` which checks its return
status and passes on the collected vector of offsets to `doTrace`.

However, if a malformed trace is passed to `recordTrace` it might partially
attach the profile to CFG and exit with false, not propagating the vector of
offsets to `doTrace`. This leads to a difference between fdata and yaml profile
collected from the same binary and the same perf file.

(Skylake LBR errata might produce such malformed traces where the last entry
is duplicated, resulting in invalid fallthrough path between the last two
entries).

There are two ways to handle this mismatch: c...

With D148542, we ran into the following libc++ build error when using musl libc.

```
.../musl/include/bits/alltypes.h:354:16:
error: definition of type '__mbstate_t' conflicts with typedef of the same name
typedef struct __mbstate_t { unsigned __opaque1, __opaque2; } mbstate_t;
               ^
.../sysroot/usr/include/bits/types/__mbstate_t.h:21:3: note: '__mbstate_t' declared here
} __mbstate_t;
  ^
1 error generated.
```
This is because the mbstate_t definition in musl libc conflicts with the one
from "bits/types/mbstate_t.h", and this patch attempts to fix this build issue
when musl libc is used.

Reviewed By: iana

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

This patch makes the following changes to `SparseTensorDimSliceAttr` methods:
* Mark `isDynamic` constexpr.
* Add new helpers `getStatic` and `getStaticString` to avoid repetition.
* Moved the definitions for `getStatic{Offset,Stride,Size}` and `isCompletelyDynamic` out of the class declaration; because there's no benefit to inlining them.
* Changed `parse` to use `kDynamic` rather than literals.
* Changed `verify` to use the `isDynamic` helper.

Reviewed By: aartbik

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

This was just a thinko. The API StackFrame::GetVariableList takes a
bool for "get_file_globals" which if true will also find file statics
and file globals. But we only were passing that as true if the
ValueType was eValueTypeVariableGlobal, which meant that we never find
file statics. It's okay if we cast too wide a net when we do
GetVariableList as later on we check against the ValueType to filter
globals from statics.

There was a test that had a whole bunch of globals and tested
FindValue on all of them, but had no statics. So I just made one of
the globals a file static, which verifies the fix.

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

Currently compiler assert when passing variable "memspace" in
omp_init_allocator.

omp_allocator_handle_t alloc=omp_init_allocator(memspace,1,traits)

The problem is memspace is not mapping to the target region.  During
the call to emitAllocatorInit, calls to EmitVarDecl for "alloc", then
emit initialization of "alloc" that cause to assert.

If I understant correct, it is not necessary to emit variable
initialization, since "allocator" is private to target region.

To fix this call CGF.EmitAutoVarAlloca(allocator) instead
CGF.EmitVarDecl(allocator).

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

/Users/jiefu/llvm-project/clang/include/clang/ExtractAPI/DeclarationFragments.h:118:26: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
    Fragments.insert(It, std::move(Fragment(Spelling, Kind, PreciseIdentifier,
                         ^
/Users/jiefu/llvm-project/clang/include/clang/ExtractAPI/DeclarationFragments.h:118:26: note: remove std::move call here
    Fragments.insert(It, std::move(Fragment(Spelling, Kind, PreciseIdentifier,
                         ^~~~~~~~~~
1 error generated.

Implement a lowering for tosa.rfft2d to linalg.generic in the
TosaToLinalg transform.

Reviewed By: eric-k256

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

Reviewed By: mysterymath

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

Fuchsia toolchain is currently broken due to
https://reviews.llvm.org/D151595. While we wait for it to be resolved,
remove BOLT to unbreak the Fuchsia toolchain build.

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

Depends On D151505

Reviewed By: aartbik, Peiming

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

(These factories are used in downstream code, despite not being used within the MLIR codebase.)

Depends On D151513

Reviewed By: Peiming

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

Depends On D151505

Reviewed By: Peiming

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

Expression evaluation for `void` valued expressions sets an error using the `kNoResult`
code. Like the `expression` command, `dwim-print` should also not print such errors.

Before:

```
(lldb) dwim-print (void)printf("hi\n")
hi
Error: 'unknown error'
```

After:

```
(lldb) dwim-print (void)printf("hi\n")
hi
```

rdar://109746544

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

In ProcessMachCore::LoadBinariesViaMetadata(), if we did
load some binaries via metadata in the core file, don't
then search for a userland dyld in the corefile / kernel
and throw away that binary list.  Also fix a little bug
with correctly recognizing corefiles using a `main bin spec`
LC_NOTE that explicitly declare that this is a userland
corefile.

LocateSymbolFileMacOSX.cpp's Symbols::DownloadObjectAndSymbolFile
clarify the comments on how the force_lookup and how the
dbgshell_command local both have the same effect.

In PlatformDarwinKernel::LoadPlatformBinaryAndSetup, don't
log a message unless we actually found a kernel fileset.

Reorganize ObjectFileMachO::LoadCoreFileImages so that it delegates
binary searching to DynamicLoader::LoadBinaryWithUUIDAndAddress and
doesn't duplicate those searches.  For searches that fail, we would
perform them multiple times in both methods.  When we have the
mach-o segment vmaddrs for a binary, don't let LoadBinaryWithUUIDAndAddress
load the binary first at its mach-o header address in the Target;
we'll load the segments at the correct addresses individually later
in this method.

DynamicLoaderDarwin::ImageInfo::PutToLog fix a LLDB_LOG logging
formatter.

In DynamicLoader::LoadBinaryWithUUIDAndAddress, instead of using
Target::GetOrCreateModule as a way to find a binary already registered
in lldb's global module cache (and implicitly add it to the Target
image list), use ModuleList::GetSharedModule() which only searches
the global module cache, don't add it to the Target.  We may not
want to add an unstripped binary to the Target.

Add a call to Symbols::DownloadObjectAndSymbolFile() even if
"force_symbol_search" isn't set -- this will turn into a
DebugSymbols call / Spotlight search on a macOS system, which
we want.

Only set the Module's LoadAddress if the caller asked us to do that.

Differential Revision: https://reviews.llvm.org/D150928
rdar://109186357

When printing the root of a value, if it's a reference its children are unconditionally
printed - in contrast to pointers whose children are only printed if a sufficient
pointer depth is given.

However, the children are printed even when there's a summary provider that says not to.
If a summary provider exists, this change consults it to determine if children should be
printed.

For example, given a variable of type `std::string &`, this change has the following
effect:

Before:

```
(lldb) p string_ref
(std::string &) string_ref = "one two three four five six seven eight nine ten": {
  __r_ = {
    std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false> = {
      __value_ = {
         = {
          __l = (__data_ = "one two three four five six seven eight nine ten", __size_ = 48, __cap_ = 64, __is_long_ = 1)
          __s = (__data_ = "@\0p\U00000001\0`\0\00\0\0\0\0\0\0\0@", __padding_ = "\x80t<", __size_ = '\0', __is_long_ = '\x01')
          __r = {
            __words ={...}
          }
        }
      }
    }
  }
}
```

After:

```
(lldb) p string_ref
(std::string &) string_ref = "one two three four five six seven eight nine ten"
```

rdar://73248786

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

This is part of an effort to migrate from llvm::Optional to std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

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

[clang][ExtractAPI] Modify declaration fragment methods to add a new fragment at an arbitrary offset.

[clang][ExtractAPI] Modify declaration fragment methods to add a new fragment at an arbitrary offset.

The current implementation doesn't support merging declaration fragments at arbitrary offsets. This patch adds that support
by modifying declaration fragment methods.

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

Extra filtering for boltdiff, excluding non-simple functions from comparison.

Reviewed By: #bolt, maksfb

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

This is a major step along the way towards the new STEA design.  While a great deal of this patch is simple renaming, there are several significant changes as well.  I've done my best to ensure that this patch retains the previous behavior and error-conditions, even though those are at odds with the eventual intended semantics of the `dimToLvl` mapping.  Since the majority of the compiler does not yet support non-permutations, I've also added explicit assertions in places that previously had implicitly assumed it was dealing with permutations.

Reviewed By: aartbik

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

These are additional tests for D151596.

This patch introduces FileSpec::GetComponents, a method that splits a
FileSpec's path into its individual components. For example, given
/foo/bar/baz, you'll get back a vector of strings {"foo", "bar", baz"}.

The motivation here is to reduce the use of
`FileSpec::RemoveLastPathComponent`. Mutating a FileSpec is expensive,
so providing a way of doing this without mutation is useful.

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

Reviewed By: ldionne, #libc

Spies: pcwang-thead, libcxx-commits

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

Apple deprecated bitcode in the deployment process in Xcode 14.0. Last
month Apple started requiring Xcode 14.1+ to submit apps to the App
Store. Since there isn't a use for bundling bitcode outside of
submitting to the App Store we should be safe to delete this handling
entirely from LLD.

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

Certifi 2022.12.07 removes root certificates from "TrustCor" from the
root store. These are in the process of being removed from Mozilla's
trust store.

https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ

Currently the PipelineSolver processes SchedGroups in bottom up manner. However, there is no compelling reason to require this. Providing the option to toggle this affords greater experimentation capability, and make usage a bit more intuitive. Importantly, it makes designing rules much easier.

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

Change-Id: Ic4abd3408f9faa105c0eef72eab7873d46083ee4

This is more consistent with how we handle integer widening multiply.

A follow up patch will add support for matching vfwmul when the
multiplicand is being squared.

This patch adds support for `tosa.scatter` lowering in the `--tosa-to-scf` pass. Here's an example for this lowering:

```
func.func @tosa(
                %valuesIn : tensor<3x7x5xi32>,
                %indices : tensor<3x6xi32>,
                %input : tensor<3x6x5xi32>) ->
                tensor<3x7x5xi32> {
        %0 = "tosa.scatter"(%valuesIn, %indices, %input) :
                        (tensor<3x7x5xi32>,
                        tensor<3x6xi32>,
                        tensor<3x6x5xi32>) ->
                        (tensor<3x7x5xi32>)
        return %0 : tensor<3x7x5xi32>
}
```

translates to
  func.func @tosa(%arg0: tensor<3x7x5xi32>, %arg1: tensor<3x6xi32>, %arg2: tensor<3x6x5xi32>) -> tensor<3x7x5xi32> {
    %c0 = arith.constant 0 : index
    %c3 = arith.constant 3 : index
    %c1 = arith.constant 1 : index
    %c6 = arith.constant 6 : index
    %c2 = arith.constant 2 : index
    %c5 = arith.constant 5 : index
    %c0_0 = arith.constant 0 : index
    %c1_1 = arith.constant 1 : index
    %0 = scf.for %arg3 = %c0_0 to %c3 step %c1_1 iter_args(%arg4 = %arg0) -> (tensor<3x7x5xi32>) {
      %1 = scf.for %arg5 = %c0_0 to %c6 step %c1_1 iter_args(%arg6 = %arg4) -> (tensor<3x7x5xi32>) {
        %extracted = tensor.extract %arg1[%arg3, %arg5] : tensor<3x6xi32>
        %2 = arith.index_cast %extracted : i32 to index
        %extracted_slice = tensor.extract_slice %arg2[%arg3, %arg5, %c0_0] [%c1_1, %c1_1, %c5] [%c1_1, %c1_1, %c1_1] : tensor<3x6x5xi32> to tensor<?x?x?xi32>
        %inserted_slice = tensor.insert_slice %extracted_slice into %arg6[%arg3, %2, %c0_0] [%c1_1, %c1_1, %c5] [%c1_1, %c1_1, %c1_1] : tensor<?x?x?xi32> into tensor<3x7x5xi32>
        scf.yield %inserted_slice : tensor<3x7x5xi32>
      }
      scf.yield %1 : tensor<3x7x5xi32>
    }
    return %0 : tensor<3x7x5xi32>
  }
```

We have attempted an alternative lowering pass that uses `tensor.scatter` as an intermediate step. However, we opted to aim straight at the `scf` dialect for the following reasons:

- The `tensor.scatter` op doesn't seem to be used anywhere. There is no available lowering pass for this op (although we have one that we'll upstream soon).
- The `tosa.scatter` and `tensor.scatter` op have different indexing semantics. The `indices` argument of `tosa.scatter` must be non-trivially modified and restructured (e.g. with a `linalg.generic` op) to adapt to the needs of `tensor.scatter`. While this overhead may be simplified and fused after a subsequent `tensor.scatter` lowering, it adds complex logic and an obscure intermediate state. Unless there is a good reason to go through the `tensor` dialect that we're missing, this additional complexity may not be justified.

Reviewed By: eric-k256

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

The rest of the fetch/op intrinsics were added in e13246a2 but sub
was conspicuous by its absence.

Reviewed By: yaxunl

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

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

Most systems support strerror_r. For the remaining systems (e.g. MSVC) strerror_s and
strerror can be used as fallbacks. We don't have a supported operating
system/compiler that doesn't provide `strerror`.

Close https://github.com/llvm/llvm-project/issues/62804

https://github.com/flang-compiler/f18/pull/1068 added a fallback
when strerror is unavailable, but I think the code path is dead.

Reviewed By: serge-sans-paille, vzakhari

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

This fixes breakage introduced by 769d282d.